Bourion 2002

Institut Spécialisé de Technologie Appliquée Hay Hassani
ISTA HAY HASSANI

Quartier Sidi EL Khadir
Hay hassani
Casablanca
RAPPORT DE STAGE
Présenté par
Meriem BENCHAMY
Sujet :.
Lieu du stage : 5, et 7 Impasse Rue Mohamed BAHI

Quartier Palmier-Maârif
Casablanca.
Effectué du… au…. (nombre de mois)

Remerciements :
Je tiens à remercier Aziz HIJJI , mon Ecadrant de stage, pour m’avoir accordé sa confiance
dans ce projet.
Merci également à mes camarades stagiaires qui par leur appui, m’ont fait progresser bien
plus vite que n’importe quel livre.
Enfin, merci à toute l’équipe de GRANDE DIFFUSION, pour son accueil, sa disponibilité et
sa bonne humeur permanente.
2
Mots clés : statistiques, données agrégées, échantillonnage, optimisation.
Résumé :
Ce stage a consisté en l’étude des méthodes de reconstruction d’une population agricole à
partir de deux sources de données : des échantillons et des données agrégées au niveau d’une
ou plusieurs sous régions. Notre rapport décrit d’abord l’analyse statistique de la population
agricole du Honduras, effectuée principalement avec le logiciel Scilab. Il détaille ensuite la
conception d’une application visant à créer une telle population à partir de ces deux sources
de données.
Abstract :
During this internship, we have studied methods of agricultural population re-creation from
samples and aggregated data at the level of several districts. First we have made a statistical
analysis of the Honduras’s agricultural population, with the Scilab software mainly. Then, we
have designed a program which creates a population from these two sources of data.
3
TABLE DES MATIERES
Introduction...............................................................................................................................................................4
I. Présentation de l’entreprise....................................................................................................................................6
II. Présentation de l’étude........................................................................................................................................11
III. Descriptif des outils acquis...............................................................................................................................14
1.LOGICIELS ET LANGAGES.......................................................................................................................................14
1.1Scilab 2.6..................................................................................................................................................14
1.2Microsoft EXCEL.....................................................................................................................................14
1.3Le langage JAVA......................................................................................................................................14
1.4Jcreator....................................................................................................................................................15
1.5Jbuilder 5..................................................................................................................................................15
1.6ArgoUML .................................................................................................................................................15
1.7WinEdit 2000............................................................................................................................................15
1.8Xanadu......................................................................................................................................................15
1.9Java analysis studio..................................................................................................................................16
2.LES MÉTHODES DE RECONSTRUCTION DE POPULATION.................................................................................................16
2.1 Méthodes de formulation du problème pour la résolution quadratique.................................................17
2.2 L’algorithme quadratique utilisé par l’application................................................................................18
2.3 Algorithmes de type génétique...............................................................................................................19
IV. L’étude..............................................................................................................................................................24
V. Conclusion..........................................................................................................................................................39
Références bibliographiques...................................................................................................................................41
ANNEXES..............................................................................................................................................................42
Introduction
Ce rapport présente les travaux que nous avons effectué au sein du LISC (Laboratoire
d'Ingénierie pour les Systèmes Complexes), unité de recherche du CEMAGREF de Clermont-
Ferrand, dans le cadre de notre stage de DESS qui s’est déroulé de début Avril à fin
Septembre 2002.
Le CIAT (Centre International de l’Agriculture Tropicale) a développé des partenariats avec

des organismes publics de recherche français, dont le CEMAGREF. L’un de ces projets
concerne l’étude de la diffusion de l’innovation agricole.
Cette étude nécessite la manipulation de données de recensement à l’échelle individuelle
(surface de l’exploitation, types et quantités de production, informations sur les
agriculteurs…).
Mais pour des raisons de confidentialité, on ne dispose généralement pas de telles données au
niveau individuel mais plutôt de données agrégées à l’échelle de la commune ou du
département et de quelques échantillons de données individuelles.
Le LISC, au cours de précédents travaux (projet européen IMAGES), a commencé à

développer des méthodes permettant de générer une population d’exploitations
statistiquement valide à partir d’échantillons et de données agrégées.
4
Notre stage a consisté à développer en JAVA un outil générique mettant en œuvre de telles
méthodes afin d’automatiser et de faciliter les opérations statistiques que nous venons de voir.
Afin de pouvoir manipuler à la fois les données individuelles et les données de recensement
agrégées nous disposions de la base de données complète du paysage agricole du Honduras.
Avant de concevoir l’application en tant que telle, nous avons donc créé des données agrégées
de cette population et testé différents outils statistiques afin d’ébaucher au mieux la structure
de données et les fonctions du programme, ainsi que les paramètres les plus représentatifs
pour la recréation de population.
5
I. Présentation de l’entreprise
1. Le CEMAGREF
Le CEMAGREF, c'est-à-dire le Centre national d'Etudes sur le Machinisme Agricole, le
Génie Rural, les Eaux et Forêts, est un établissement public à caractère scientifique et
technologique (EPST). Il existe depuis 1981 et comporte aujourd’hui 32 unités de recherche
réparties dans toute la France sur 10 groupements géographiques. Il dépend à la fois du
ministère de l'Education nationale, de l'Enseignement Supérieur, de la Recherche et de la
Technologie et du ministère de l'Agriculture, de la Pêche et de l'Alimentation.
1.1 Ses Activités

Outre la contribution au progrès des connaissances, le CEMAGREF diffuse des méthodes de
diagnostic et de contrôle, il développe des outils de négociation et de gestion, il conçoit des
technologies innovantes et apporte son expertise aux services publics et aux entreprises.
La figure suivante montre de manière synthétique ses principales activités et ses principaux
partenaires :
Figure 1 : Activités du CEMAGREF
6
Les compétences du CEMAGREF s’orientent sur quatre grands domaines d’étude, qui
constituent chacun un département scientifique :
- le fonctionnement des hydrosystèmes,

- le génie des équipements et services pour l’eau et les déchets,
- la gestion des territoires à dominante rurale,
- le génie des équipements dans le secteur agricole et alimentaire.
Pour les années à venir, les deux priorités scientifiques du CEMAGREF concernent les
hydrosystèmes et leurs relations avec l'agriculture d'une part, la gestion des risques naturels
d'autre part.
Les méthodologies scientifiques telles que modélisation, information géographique et
informatique scientifique, qui constituent un apport essentiel à la recherche en ingénierie sont
également privilégiées.
• Produits de la recherche
Les recherches et les activités conduites au CEMAGREF donnent lieu à des produits variés.
Ainsi, les publications, les participations à des colloques, les expertises et conseils aux
services publics, les essais et analyses, les brevets et logiciels, la formation initiale et
continue, la participation à la normalisation illustrent les missions de l'institut.
Pour ces productions, adaptées aux utilisateurs auxquelles elles sont destinées, le
CEMAGREF met en place une démarche qualité, aujourd'hui acquise pour les essais et les
analyses, en cours pour les activités de recherche.
Les produits du CEMAGREF sont :
- Les publications (740 publications/an),

- les participations à des colloques (320 communications/an),
- les expertises et conseils aux services publics (800 mois-ingénieurs/an),
- les essais et analyses (560 mois-ingénieurs/an),
- les brevets (28),
- les logiciels (10 commercialisés),
- la formation initiale et continue (10 % du temps/an des ingénieurs et des chercheurs
dans plus de 50 universités),
- la participation à la normalisation (30 mois-ingénieurs/an).
1.2 Ses Ressources humaines

Le CEMAGREF emploie environ 1 000 permanents dont 450 ingénieurs et chercheurs. Leurs
compétences, centrées sur les sciences de l'ingénieur, intègrent les sciences de la nature et du
vivant, les sciences de l'univers et mobilisent les sciences humaines et sociales. Leur origine
diversifiée facilite la construction de partenariats variés. Le CEMAGREF accueille en
moyenne une centaine de thésards et 500 stagiaires de longue durée.
L'effectif des ingénieurs et chercheurs se répartit équitablement selon les grandes orientations
scientifiques, comme le montre la figure :
7
Gestion des
territoires à
dominante rurale : Administration de
19% la recherche : 21%
Génie des Valorisation et

équipements et animation de la
services pour l'eau recherche : 10%
et les déchets :
17% Génie des
Fonctionnement
équipements dans
des
le secteur agricole
hydrosystèmes :
et alimentaire :
16%
17%
Figure 2 : Effectif des ingénieurs et chercheurs
Deux tiers des emplois sont financés par le budget civil de la recherche et du développement.
Le dernier tiers est mis à disposition principalement par le ministère de l'agriculture, de la
pêche et de l'alimentation.
1.3 Son Budget

Le budget 2001 est de 63 millions d’euros (413 MF). Les recettes provenant des contrats
s'élèvent à 13 millions d’euros (85 MF) et assurent l'essentiel des moyens de fonctionnement
des unités de recherche. Chaque année, plus de 150 contrats de recherche et de transferts sont
signés.
La figure suivante montre la répartition des dépenses pour 2001 :
Fonctionnement
général : 29 MF
Activité
scientifique : 112
MF
Personnel
permanent
(rémunéré par
l'Etat) : 272 MF
Figure 3 : Répartition des dépenses
8
2. Le CEMAGREF en région Auvergne-Limousin
Le groupement de Clermont–Ferrand, l’une des 9 délégations du territoire français, est

implanté sur le campus scientifique des Cézeaux ou en plus de son rôle d’institut de recherche
il s'applique à développer des partenariats scientifiques, d'enseignement supérieur et de
formation. Il possède également une antenne à Montoldre (Allier).
Le CEMAGREF de Clermont-Ferrand est constitué de 3 unités de recherche, qui ont la

particularité d’appartenir à des départements scientifiques différents :
- DFCF : Dynamiques et Fonctions des espaces ruraux

- TSCF : Technologies, Systèmes d'information et procédés pour l'agriculture et
l'agroalimentaire (C’est l’unité la plus importante en terme de personnel)
- LISC : Laboratoire d'Ingénierie des Systèmes Complexes
3. Le LISC
Le LISC est une unité qui n’appartient en fait à aucun des quatre départements scientifiques
définis à l’échelon national, mais est rattachée directement à la direction scientifique du
CEMAGREF.
Et du fait de son statut interdisciplinaire, l’unité de recherche participe à des projets
scientifiques en collaboration avec les quatre départements.
Le rôle du LISC est d’évaluer et de développer des méthodes de modélisation de systèmes

complexes. Ce travail est mené en collaboration étroite avec les équipes thématiques de
l’établissement et des partenaires extérieurs au travers de projets communs, souvent
interdisciplinaires.
Les recherches font appel à diverses disciplines, dont les principales sont les mathématiques
appliquées, les statistiques, l'informatique et l'intelligence artificielle. Les aspects théoriques
et informatiques des modèles sont développés dans le cadre de projets en partenariat avec des
équipes thématiques. La recherche se déploie dans trois directions principales :
- les modèles dynamiques distribués spatialement,

- les modèles statistiques et les bases de connaissances,
- les méthodes et outils d'utilisation collective de modèles dans une négociation.
Le thème de recherche de l’unité, MAGESTYC (Modèles pour l’Aide à la GESTion des

sYstèmes Complexes), vise à élaborer, tester, valider des méthodes de modélisation
génériques utilisables dans les domaines du CEMAGREF : écosystèmes, dynamiques sociales
et interactions avec le milieu, interactions entre équipements et milieux naturels.
Le travail de recherche se concentre particulièrement sur l’utilisation de modèles
géométriques dynamiques, qui permettent de définir l’évolution locale de formes, à diverses
9
échelles. Ces modèles sont élaborés dans une démarche incrémentale, en étroite liaison avec
des experts du terrain et des domaines abordés. Leur confrontation aux historiques de données
disponibles et à l’appréciation des acteurs est une question particulièrement sensible. Les
applications principalement visées sont des outils de gestion de la connaissance, généralement
destinés aux experts d’un domaine, ou directement des outils d’aide à la décision ou à la
négociation pour les acteurs de terrain et les décideurs publics.
4. Le CIAT et Le CGIAR
Basé à Cali, en Colombie le CIAT (Centre International de l’Agriculture Tropicale),
organisme à l’origine de notre projet, est en fait un des centres de recherche du CGIAR
(Consultative Group on International Agricultural Research).
Crée en 1971, Le CGIAR est une association internationale dont les membres publics et
privés supportent 16 centres dans plus d’une centaine de pays.
Son but est d’utiliser l’outil scientifique pour améliorer la production agricole et d’apporter
des solutions aux problèmes de nutrition, de santé et d’environnement des pays tropicaux
principalement.
Plus de 8500 chercheurs travaillent au CGIAR et les produits de leur recherche débouchent
dans le domaine public.
10
II. Présentation de l’étude
1. Origine et contexte du stage

Le CIAT (Centre International de l’Agriculture Tropicale), pour étudier la diffusion de
l’innovation agricole dans les pays concernés par son action, doit disposer de données de
recensement à l’échelle individuelle ou familiale. (Ces données sont des informations sur
les exploitants, les terrains et les productions des fermes).
Or, non seulement les recensements sont peu nombreux et espacés dans le temps, mais il
est rare que ceux ci soient disponibles de manière exhaustive. Souvent on ne dispose, pour
des raisons de confidentialité, que d’échantillons (de taille variable, mais représentatifs de
la population) et de données agrégées à l’échelle du village, de la commune ou de districts
supérieurs.
Il faut donc à partir de ces deux sources de données pouvoir recréer une population
statistiquement valide, avec une erreur minimale d’erreur entre population générée et
population réelle.
Le CIAT a donc développé un partenariat avec le LISC, du CEMAGRF de Clermont-

Ferrand, qui a commencé à développer des méthodes de recréation de population lors du
projet IMAGES (CT 96 2092), projet qui concernait l’étude des décisions des agriculteurs
européens sous l’application de la Politique Agricole Commune (PAC).
L’objectif premier de notre stage au sein du LISC a donc été de concevoir une application
dotée d’une interface conviviale qui effectuerait cette recréation de population à partir de
données agrégées et d’échantillons. Nous allons maintenant voir plus en détail les
objectifs et contraintes du programme.
2. Spécifications de l’application
Voici les spécifications qui sont apparues au début de l’étude :
• Le programme sera codé en JAVA, langage dont la robustesse et l’approche
objet conviennent parfaitement pour une telle application, et qui n’a pas
besoin de hautes performances en termes de vitesse d’exécution. De plus,
programme et code sources seront disponibles en libre accès : il ne doit donc
pas y avoir de classes protégées par copyright ni d’appels à des modules
externes appartenant à des applications payantes.
• Le programme devra reposer sur une interface graphique suffisamment
intuitive pour permettre à l’utilisateur néophyte de le faire fonctionner
rapidement sans recourir constamment à un mode d’emploi.
• Il devra comporter un module de localisation car il sera utilisé par des
personnes de langue espagnole ou anglaise.
• L’outil doit être générique : On doit pouvoir traiter des données d’entrée qui
varient selon la population étudiée :
11
- Le nombre de paramètres est variable et ceux-ci peuvent être qualitatifs
ou quantitatifs : ils doivent être reconnus comme tels par le programme,
- Le nombre de niveaux d’agrégation (échelles géographiques) peut
varier.
• Il y a donc nécessité de garder une certaine souplesse pour définir la structure
des fichiers d’entrée. Les contraintes de format devront être suffisamment
souples pour tenir compte de la variété des cas rencontrés.
Au fur et à mesure du déroulement du stage, de nouveaux objectifs sont apparus :

Le principal a été d’envisager d’ajouter au programme la fonction « inverse » de celle qu’il
effectue : C’est à dire créer un échantillon représentatif (au taux d’erreur désiré) à partir de la
population entière. Cet ajout trouve tout son intérêt car on rencontre de plus en plus le besoin
de créer un échantillon type a partir d’une population mère : pensons par exemple à un bureau
de recensement, ou une agence publicitaire désireuse de connaître les profils types de ses
clients pour mieux les cibler.
C’est une manipulation qui demande peu d’ajout de code, car les structures de données et les
fonctions d’optimisation demeurent les mêmes. Le seul problème étant la quantité de mémoire
requise pour charger la matrice de population entière.
Voyons maintenant plus précisément les spécifications du programme en décrivant les

différents modules qu’il comportera (en termes de code, un module correspondra à une ou
plusieurs classes ou même un package) :
• Module « population »
Il contiendra toutes les variables concernant les données de la matrice de population, les
données agrégées, les échelles…
• Module « statistiques »
Le programme doit disposer de nombreux outils pour faire l’agrégation des données : les
plus classiques comme moyenne, somme, variance, écart-type mais aussi d’autres qui
sont de plus en plus utilisés, comme les quantiles. On pourra également rajouter des
modules plus complexes comme des analyses factorielles des correspondances, des
analyses par clusters…
• Module « optimisation »
Il comportera au moins 2 algorithmes de minimisation pour optimiser le taux d’erreur lors
de la recréation de population :
Un algorithme quadratique et un algorithme de type génétique, qui travailleront
séparément ou ensemble.
Notons qu’au début du projet, il était prévu de rechercher dans la littérature un

algorithme quadratique qui conviendrait au mieux au problème mais le temps et la
complexité qu’impliqueraient son codage nous ont incité à rechercher un algorithme déjà
écrit : Or il existe peu de tels algorithmes disponibles dans le domaine public : celui de
Scilab (appelé par la fonction " optim") s’est révélé vaste et incompréhensible, car il
contient de nombreuses routines en Fortran non documentées. Nous avons finalement
opté pour un algorithme venant de "R" : un environnement de calcul statistique en sources
libres.
12
• module « visualisation »
Ce module servira à visualiser les différentes données traitées par le programme sous
forme graphique. Nous avons projeté de l’élaborer à partir de JAS (Java Analysis Studio),
un package gratuit spécialisé dans cette tâche.
• Un module « plan d’expérience »

Comme son nom l’indique, il servira à établir facilement des plans d’expériences mais il
permettra aussi de les mémoriser.
3. Planning du stage
• Première quinzaine d’avril : bibliographie sur les méthodes d’optimisation
(algorithmes quadratiques et génétiques) et articles sur les méthodes
statistiques de recensement de population.
• Deuxième quinzaine d’avril à mi-juin : Analyse de données avec Scilab sur la

population du Honduras : calcul des données agrégées pour les paramètres de
terrains, les paramètres de producteurs puis analyse des corrélations.
Découverte du langage JAVA et entraînement à la conception d’interfaces
graphiques (avec jcreator).
• Fin juin à mi-juillet : Définition de la structure du programme, Conception

UML du diagramme de classes, ébauche de l’interface graphique.
• Mi-juillet à fin août : Codage du programme. Rédaction du rapport.
• Mois de septembre : codage, perfectionnement et ajout de nouveaux modules.
13
III. Descriptif des outils acquis
Durant ce stage nous avons nettement amélioré nos compétences en langage orienté objet
(vues en DESS avec le langage C++), grâce à la pratique de l’UML et du langage JAVA.
Nous avons également manipulé des outils statistiques tels que Scilab. Enfin nous avons
abordé des méthodes d’optimisation de type quadratique et génétique pour les besoins de
notre application.
1. Logiciels et langages
1.1 Scilab 2.6
Scilab (pour Scientific Laboratory) est un programme français de statistiques et de
mathématiques gratuit et en sources libres (licence GNU), développé par l’INRIA depuis
1989. Il regroupe de nombreuses et diverses fonctions visant à faciliter le travail sur des
groupes de données (matrices et vecteurs).
Nous n’avons pas utilisé le logiciel Matlab, plus performant mais payant, pour rester dans une
optique de gratuité des outils et des travaux fournis : En effet, le programme et les outils qui
lui sont associés pour le pré-traitement des données, tels que Scilab, doivent être en sources
libres.
1.2 Microsoft EXCEL

Nous avons utilisé Excel en appui à Scilab pour plus de facilité dans l’édition des données
agrégées et la création de graphiques.
Si le logiciel est performant pour ces tâches d’édition et de présentation il n’est cependant pas
d’une grande efficacité pour les fonctions statistiques (nombre de lignes limité à 65000,
mauvaise gestion des intervalles de classe dans les graphiques…).
1.3 Le langage JAVA

Créé en 1995 par la société Sun, ce langage objet est en constante amélioration et connaît un
grand succès dans le monde grâce à ses nombreux avantages :
Il est syntaxiquement proche du C++, ce qui facilite le passage de l’un à l’autre.
Il est multi plate-forme (seule l’installation de la machine virtuelle est requise)
Il est robuste : c’est un langage complètement objet, très typé et qui possède beaucoup de
gestions d’exceptions.
Il possède beaucoup de fonctions simplifiées grâce à un panel de classes livrées avec le JDK,
à la suppression des pointeurs et la gestion de la mémoire par le Garbage Collector.
La conception d’interfaces graphiques est rendue très simple par les composants AWT et
swing.
Le langage JAVA possède néanmoins des points noirs comme sa relative lenteur (car c’est un
langage interprété), ou bien l’absence d’héritage multiple (compensée par les interfaces).
14
Durant ce stage nous avons utilisé le JDK 1.3.
(Nous avons écarté le JDK 1.4 car il est trop récent et souvent des problèmes incongrus
peuvent se poser avec modules externes ajoutés).
Nous avons utilisé les composants graphiques SWING plutôt que les composants AWT car ils
sont plus complets et optimisés.
1.4 Jcreator
Plus exactement : Jcreator 2.00 LE (Lite Edition) de Xinox software : c’est une version
gratuite de ce logiciel de développement en JAVA.
Nous l’avons utilisé au début de notre stage lors de notre initiation au langage JAVA
Il est complet, tout en étant très léger, et son interface ressemble trait pour trait à celle de
Microsoft Visual C++.
Le seul hic est qu’il ne possède pas de débogueur intégré.
1.5 Jbuilder 5
Borland Jbuilder (utilisé avec le JDK1.3) est un éditeur de développement JAVA proposant
une interface de conception visuelle complète
Nous l’avons choisi en raison de sa capacité à créer rapidement une interface graphique.
De plus, de nombreux assistants, audits de code et classes types permettent d’accélérer le
codage.
Cependant certaines des classes qu’il utilise sont sous licence et ne sont donc pas portables à
l’extérieur, car notre programme requiert une gratuité complète.
1.6 ArgoUML
ArgoUML permet de faire des diagrammes en modélisation UML puis de générer du code
JAVA à partir de ceux-ci.
ArgoUML est en version 0.10 : il est en cours de développement et donc pas très stable. Son
successeur, nommé Poseïdon, fonctionne mieux mais est plus lourd. Nous avons donc préféré
utiliser ArgoUML car nous l’avons utilisé uniquement pour faire le diagramme de classes du
programme.
1.7 WinEdit 2000

WinEdit est un éditeur de texte très complet qui remplace avantageusement le bloc-notes et
devient indispensable pour lire les très gros fichiers texte telles que les matrices de paramètres
utilisés durant notre stage.
1.8 Xanadu
Ce petit logiciel gratuit permet de traduire facilement un mot dans la langue souhaitée.
C’est en fait une sorte de moteur de recherche qui affiche dans un onglet une page de réponses
pour chacun des différents sites de traduction on-line auxquels il a fait sa requête.
La multiplicité des réponses, la non présence de publicité et la simplicité d’utilisation en font
un outil très agréable à utiliser.
Nous l’avons utilisé pour des traductions de l’espagnol et de l’anglais.
15
1.9 Java analysis studio
JAS (version 2.2.5 ) est une application gratuite et multi-plateforme qui a pour ambition de
faciliter l’affichage et l’analyse de données, indépendamment de leur format ou de leur nature.
Elle dispose de nombreuses fonctions statistiques et d’une interface graphique très riche et
intuitive permettant
Le code source étant disponible, nous comptons utiliser certaines de ses classes pour le
module de visualisation.
Nous allons à présent voir les différentes méthodes d’optimisation étudiées pour les besoins
du programme.
2. Les méthodes de reconstruction de population

Décrivons d’abord d’une manière générale la méthode de reconstruction de population à partir
de données agrégées et d’échantillons que nous allons utiliser :
On définit d’abord tous les individus de l’échantillon comme des « prototypes » : chaque
prototype représente une exploitation agricole type.
Cet échantillon ne devra pas être trop petit et représenter suffisamment bien la population
initiale (échantillon non biaisé), ce qui n’est pas toujours évident dans la pratique.
On va ensuite attribuer des coefficients (appelés λi ) à chaque prototype. Le produit des

prototypes par leurs coefficients nous donnera une nouvelle population. Tout le travail
d’optimisation consiste donc à choisir de façon optimale ces coefficients afin de respecter les
contraintes imposées par les données agrégées.
Ce problème apparaît donc comme la résolution d’un système linéaire. Cependant, dans la
majeure partie des cas, un tel système ne possède pas de solution.
Nous devrons donc le transposer en un problème quadratique, ce qui permettra d’obtenir à
priori une solution optimale.
Mais on peut également approcher le problème sous une toute autre approche, qui est celle
des algorithmes de type « génétique » :
Ceux ci aboutissent en général rapidement à une solution sub-optimale mais ensuite, au fil des
itérations, leur progression devient très lente, avec peu d’assurance d’atteindre la solution
optimale.
Il est cependant intéressant de comparer leurs solutions avec celles des algorithmes de type
quadratique.
Nous allons d’abord voir la méthode utilisée pour transformer le problème linéaire en un
problème quadratique puis nous présenterons l’algorithme quadratique utilisé dans le
programme et enfin nous allons comparer différents algorithmes de type génétique.
16
2.1 Méthodes de formulation du problème pour la résolution
quadratique
Pour le problème qui nous concerne, résoudre un système quadratique revient à trouver le
minimum d’une somme quadratique de différences.
Nous allons étudier ceci en partant d’un exemple assez simplifié où deux types de paramètres
sont utilisés : le nombre de producteurs et les différentes productions.
Considérons une population P initiale, constituée de N individus (agriculteurs).
Ces agriculteurs produisent K sortes de produits k.
Considérons maintenant notre échantillon : une population P’ de n individus : ce sera donc
l’ensemble des prototypes à partir desquels nous allons générer une population P’’ semblable
à P.
Considérons que les paramètres de notre population P sont :

- nkP : nombre d’agriculteurs de P produisant k
- Et QkP : quantité de k produite dans P.
Nous noterons également Qki la quantité de k produite par l’individu i de P’.
La problème peut alors s’écrire sous cette forme :
K K
m{ xi } (∑i αn (n − n ) + (∑ β (Q − Q ) )
P G2
k k
P G2
k k
k= 1 k= 1
n
avec ∑x =N
i =1
i
n n
Où nkG = ∑a i =1
k
i xi et QkG = ∑a Q x
i =1
k
i
i
k i
Les variables de décision du problème sont :
k
-
a i
= 1 si xi produit k.
k
-
a i
= 0 si xi ne produit pas k.
17
α et β sont des coefficients de pondération : ils servent à donner plus ou moins d’importance à
certains paramètres.
Sous une autre formulation, le problème devient :
K n K n
m{ xi } (∑i αn (n − ∑ a x ) + (∑ β (Q − ∑ a Q x ) ) P
k
k 2
i i
P
k
k i 2
i ki
k= 1 i= 1 k= 1 i= 1
n
avec ∑x =N
i =1
i
Développons maintenant ce polynôme du second degré en xi, nous obtenons :

 k
( )
k = 1  i= 1
i2
i> j
k
n
i= 1
( )
P= ∑  ∑ ai α + β kQk xi + ∑ aik*a j (α + β kQkiQkj ) xi xj − 2∑ aik α nkP + β k QkpQki xi )
n n 2
Et nous reconnaissons la forme quadratique suivante :
xt * Q*x + 2*pt * x,
où x=(xi), Q=(qij) et p=(pi) avec :

qij =∑ai a j (α +βk Qki Qkj ) pour i >= j , i,j=1..n.
k k
qij = 0 pour i >= j , i,j=1..n.
pi = − 1*∑ a  α n + β Q Q 

n
k p i
P k k k
i k
k
Si nous notons I la matrice identité, le problème devient, avec les notations ci dessus:
min (0.5*xt*Q*x+pt*x)
I*x=N
C’est cette formulation qui sera utilisée lors de la résolution par le programme.
Il faudra donc calculer et fournir, entre autres, à la routine d’optimisation la matrice Q et le
vecteur p.
2.2 L’algorithme quadratique utilisé par l’application

L’algorithme utilisé par notre programme ne sera pas codé dans une classe mais sera en fait
appelé par un module extérieur : « R »
Le projet « R » (www.r-project.org) est un langage et un environnement pour le calcul

statistique et l’affichage graphique. Il est gratuit et en sources libres car il est développé sous
licence GNU. Il fonctionne sous de nombreuses plates-formes (Windows, linux, Mac…).
18
R possède de nombreuses fonctions statistiques évoluées, et peut facilement en intégrer de
nouvelles, par l’ajout de packages.
L’algorithme d’optimisation quadratique de R est décrit par Goldfarb et Idnani (1983) :

Il consiste en fait en une série de méthodes de programmation quadratique. Ils le décrivent
comme un algorithme dual efficace et numériquement stable pour les problèmes quadratiques
entiers positifs.
Sa particularité est d’utiliser le minimum non contraint de la fonction objectif comme point
de départ.
De plus son implémentation utilise les factorisations de Cholesky et de type QR et les
procédures pour les mettre à jour.
2.3 Algorithmes de type génétique
Nous entendons ici par algorithmes de type génétique tous les algorithmes n’utilisant pas de
méthodes analytiques, ou ne pouvant être décrits précisément ou bien dont la solution exacte,
si elle est connue, est trop compliquée pour être calculée en un temps raisonnable.
Voyons un comparatif entre les deux approches, qui se révèlent complémentaires :
Approche ad hoc (analytique, spécifique) Approche génétique
Rapidité Selon solution, parfois bonne Bonne à très bonne
Performance Selon solution Bonne
Compréhension Nécessaire Non nécessaire

du problème
Travail humain Très variable : De quelques jours à quelques Faible : Quelques jours
thèses ou semaines
Applicabilité La plupart des problèmes intéressants n'ont pas Générale

d'expression mathématique exploitable, ou sont
non-calculables, ou NP-complets.
Etapes ne sont pas des solutions (il faut attendre la fin sont des solutions (le
intermédiaires… des calculs) processus peut être
interrompu à tout
moment)
Pour notre problème utiliser de telles méthodes signifiera, comme pour un algorithme
quadratique, générer des coefficients λi pour multiplier les prototypes de façon à minimiser
au maximum l’erreur entre données agrégées initiales et données agrégées générées.
Mais ici, au lieu de chercher la valeur des λi, nous leur donnons une valeur de départ
quelconque puis nous les modifions petit à petit selon diverses méthodes, en observant si
l’erreur résultante a été diminuée ou pas. C’est le nombre d’itérations qui est déterminera la
19
qualité de la solution : si celle ci progresse vite au départ, elle atteint ensuite une phase de
plateau.
Williamson et coll.(1998 ) ont exposé un éventail de méthodes de type génétique pour des
travaux d’estimation de population à partir des échantillons du recensement de 1991 au
Royaume Uni. Ces travaux correspondant assez aux nôtres, nous allons pouvoir adopter l’une
de ces méthodes pour notre programme, sans avoir à trop la modifier.
Nous allons donc passer en revue ces différentes méthodes et garder la meilleure.
Tout d’abord examinons la méthode la plus basique que l’on puisse imaginer : Essayer toutes
les combinaisons possibles de coefficients multiplicateurs λi pour un échantillon donné : Le
problème se révèle tout de suite gigantesque pour une base de données telle que la nôtre! Il
faut donc trouver des méthodes plus élaborées pour arriver rapidement à une solution, en
général sub-optimale.
Voyons les 3 méthodes proposées par les auteurs, et leurs variantes :
1. L’approche “Hill climbing”(Ascension de colline)
Par cette méthode, on n’essaie plus toutes les combinaisons possibles mais on en choisit une
seule, puis on fait quelques changements minimes : si l’erreur est diminuée on conserve les
changements, sinon on les rejette, puis on fait de nouveaux changements.
Cette méthode a l’avantage de faire diminuer rapidement l’erreur globale mais son gros
problème est que si on arrive a un pic sub-optimal (minima local de la fonction qui n’est pas
le minima absolu) on ne peux plus « en sortir », car l’approche hill climbing veux que l’on
progresse toujours dans un seul sens.
Voici le déroulement de cette méthode :
a) on dispose d’un échantillon, (ou bien on le choisit au hasard dans la population initiale, 1%
par exemple).
b) on multiplie chaque prototype de l’échantillon par des coefficients λi (de valeur quelconque
au début).
c) On calcule l’effectif des contraintes observées à partir de la nouvelle population générée.
d) On calcule (ou on connaît) l’effectif des contraintes attendues de la population initiale.
e) On calcule un indicateur d’erreur appelé TAE (total des erreurs absolues) :

TAE = somme des valeurs absolues des différences entre valeurs des contraintes observées
(générées) et valeurs des contraintes théoriques (dont on dispose au départ).
Si le TAE atteint la valeur de 0 alors la solution est optimale.
Le choix de cet indicateur est préférable à un test de χ² qui, selon les auteurs, n’est pas adapté
à ce genre de population (car des valeurs de paramètres très disparates aboutissent à un khi ²
anormalement fort). Les autres tests paramétriques sont également proscrits du fait de la
grande auto-corrélation qui règne souvent entre les paramètres.
20
f) On change la valeur de quelques λi (au hasard ou pas) et on recalcule le TAE : si le TAE a
diminué on conserve les changements opérés, sinon on revient à la précédente configuration.
Puis on recommence un très grand nombre de fois cette méthode , jusqu'à trouver un TAE
acceptable.
Voyons deux variantes de cette méthode :
HC 1 : On fait un simple remplacement de coefficients λi au hasard.
HC 2 : Le seul changement consiste, au lieu de sélectionner des coefficients λi au hasard, à

étudier la contribution pour le TAE de plusieurs valeurs de λi pour chaque élément
(prototype) et d’éliminer celles qui augmentent le plus l’erreur totale.
La méthode HC2 semble plus efficace que HC1 mais pourtant c’est cette dernière qui a les
meilleurs résultats. En effet, à l’expérience, HC2 tombe rapidement dans des pics sub-
optimaux et est plus lente, ceci étant dû à la perte de diversité due à sa sélectivité supérieure.
2. L’approche “simulated annealing” (recuit simulé)
Le principe de base du recuit simulé est emprunté à la métallurgie : on chauffe un morceau de

métal, puis on le laisse refroidir lentement. Le refroidissement lent et régulier du métal permet
aux atomes de se stabiliser peu à peu dans une position d'énergie minimale. Ici nous allons
minimiser, non pas l'énergie d'un cristal, mais une fonction de coût (erreur totale)
caractéristique du problème, où une solution est d'autant meilleure que son coût est faible.
La méthode permet le « back-tracking » : c’est à dire pouvoir redescendre d’un pic sub-
optimal (augmenter temporairement l’erreur) pour atteindre plus tard un pic de moindre
erreur.
Son fonctionnement repose sur une formule de thermodynamique :
P(δE) = exp (-δE / T)

Avec :
P = probabilité (d’augmentation)
δE = augmentation potentielle du TAE (changement potentiel de performance de
recombinaison).
T = niveau maximum de dégradation de performance acceptable pour la modification d’un
élément dans une combinaison.
Il en découle que :
Plus δE est faible et plus la probabilité d’un changement potentiel sera grande.
Plus T est faible et moins une baisse importante de performance sera acceptée.
Le déroulement de cette méthode est semblable à celui du hill climbing hormis que les
changements prévus sont soumis à cette formule.
Si un élément augmente la performance globale (diminution de l’erreur), il est

automatiquement accepté.
21
Si un élément diminue la performance globale il ne sera accepté que si P(δE) est supérieure
ou égale à un nombre aléatoire compris entre 0 et 1.
La méthode du « simulated annealing » a été testée en deux variantes, qui varient seulement
au niveau des valeurs de T initiales :
SA1 : Au départ on fixe T comme la variation maximum de TAE pouvant être créée par un
changement de coefficient.
La période pour laquelle T diminue a été fixée à 10*T. ( c’est un ratio empirique qui donne de
très bons résultats).
SA2 : T est choisie plus faible mais la période de diminution de T l’est aussi, car on garde le
même ratio : 10*T . Ceci a pour conséquence de faire ressembler la méthode à un hybride
avec la méthode hill climbing.
SA2 fonctionne beaucoup mieux que SA1, qui est handicapée par de trop grandes fluctuations
dues à la facilité de sortir des pics sub-optimaux.
Il faut donc, dans cette méthode, minimiser le plus possible le back-tracking, sans toutefois le
supprimer.
3. L’approche par algorithme génétique
L’algorithme génétique au sens strict s’appuie sur une vision « évolutive » empruntée à la
biologie.
Il fait intervenir des entités appelées chromosomes, qui sont les vecteurs de la reproduction,
c’est à dire la transmission de l’information d’une itération de l’algorithme à une autre. Dans
notre cas on pourra définir un chromosome comme un ensemble de coefficients λi. Chaque
chromosome possède un niveau de santé (fitness) qui correspond au complément de sa
contribution au TAE selon un nombre arbitraire. Ainsi, seuls les chromosomes ayant le
meilleur niveau de santé pourront se reproduire. La reproduction fonctionne par un processus
appelé croisement (cross-over) : deux chromosomes parents s’échangent équitablement leur
information (les coefficients dans notre cas) et créent ainsi deux chromosomes fils.
Il peut y avoir plusieurs croisements et le taux d’information transmise peut varier.
De plus plusieurs mécanismes peuvent intervenir sur ce processus :
- L’élitisme : On considère qu’un certain pourcentage des chromosomes les plus sains
(meilleurs niveaux de santé) feront partie de la génération suivante sans passer par la
reproduction.
- La mutation : On intervient sur le croisement entre deux parents en ajoutant une

probabilité (faible) de non-transmission d’un élément d’un parent à un enfant, qui
conserve alors son élément d’origine. Ceci permet d’injecter ou de réinjecter de la
diversité dans le déroulement de l’algorithme car la sélection perpétuelle par le niveau
de santé fait décroître progressivement cette diversité.
22
Cinq variantes de l’algorithme génétique ont été testées. Elles variaient sur plusieurs
paramètres : nature de la fonction de calcul du niveau de santé, taux d’élitisme, nombre de
croisements, taux de mutation…
Les performances de chacune de ces variantes importent peu ici, car aucune n’est meilleure
que les algorithmes hill climbing ou simulated annealing.
Au final nous retiendrons que c’est l’algorithme SA2 (simulated annealing avec une faible
valeur de T) qui donne les meilleurs résultats. C’est donc celui-ci que nous choisirons et
implémenterons dans notre application.
23
IV. L’étude
Cette étude pourrait se décomposer de manière grossière en 2 grandes parties :
D’abord l’analyse des données puis la réalisation du programme.
1. Analyse des données

1.1 Présentation des données
Les Données dont nous disposions pour faire notre étude viennent d’un recensement effectué
au Honduras : Ce recensement a porté sur tout le pays et concernait la population agricole.
Le questionnaire soumis aux exploitants portait sur trois types d’informations :
• Les caractéristiques du producteur,

• Les caractéristiques des exploitations (subdivisées en 2 parties : propriété des
terres et usage des terres),
• Les productions (nature des productions et leur quantités).
Le recensement a donc engendré une base de données pour chacun de ces domaines, mais il a
également établi les localisations de chaque ferme recensée sous forme de coordonnées
spatiales (position X et Y) et sous forme de référence aux districts auxquelles elles
appartiennent.
Le Honduras, petit pays d’Amérique Centrale (112088 km² et 5 600 000 habitants) est
structuré administrativement selon 3 échelles principales :
Les départements, qui contiennent des municipalités, qui contiennent des villages.
Carte administrative du Honduras
24
De façon chiffrée le pays comporte :
- 18 départements
- 290 municipalités (soit environ 16 municipalités par département)
- 3760 villages (soit environ 13 villages par municipalité)
- 317187 fermes (soit 84 fermes par villages)
Chaque ferme possède un identifiant unique de 12 chiffres, constitué d’un « code village » de
5 chiffres, plus 7 chiffres propres à la ferme.
Ce code village contient aussi en lui même les codes de municipalité et de département de la
ferme concernée. L’identifiant d’une ferme contient donc tous les codes d’échelle.
Examinons maintenant plus en détail les 3 bases de données du recensement :

- Les paramètres d’exploitation : Ce sont toutes des surfaces, et elles sont données en Ha.
En voici la liste des paramètres : il y a d’abord la liste des propriétés des surfaces puis l’usage
des terres :
EXPLOITATIONS
numéro paramètre
1 terrains propres (personnels)
2 terrains nationaux
3 Ejidales (non traduit)
4 propriété des terres Terrains loués
5 Terrains occupés (sans contrat)
6 sous total
7 Terrains loués à un tiers
8 total de l'exploitation
9 cultures annuelles
10 cultures permanentes
11 repos long (plus d’un an)
12 repos court (moins d’un an)
13 pâturages naturels
usage des terres
14 pâturages cultivés
15 bois, forêts
16 étangs, lacs…
17 autres usages agricoles
18 autres usages non agricoles..
- Les paramètres des producteurs : ce sont des données qualitatives sur les exploitants, codées
sous forme de classes (exemple : 5 classes de condition juridique) ou bien binaires
(Homme/Femme) :
PRODUCTEURS
1 condition juridique
2 age
3 sexe
4 alphabétisation
5 Plus haut niveau d'études atteint
6 Plus niveau d'études validé
7 type de questionnaire
25
- Malheureusement les données de productions n’ont pas pu nous parvenir à temps, ni pour
faire l’analyse de données, ni pour les utiliser avec le programme (bien que celui soit
configuré pour les accueillir).
Ces données (qui contenaient les types de production et leur quantité) étaient en fait sous
forme de base de données relationnelle, car pour une ferme donnée il peut y avoir plusieurs
productions (de culture ou d’élevage).
Notons que, cette base de données étant peu compatible avec la structure de données du
programme, il était prévu lors de la phase de conception de la convertir en une base unique,
toutes les productions d’une ferme et leurs caractéristiques étant affichées sur une seule ligne.
Pour terminer, la base de données des coordonnées spatiales des fermes : nous ne l’avons pas
utilisé pour l’instant mais nous notons qu’elle représente un outil intéressant pour des
recherches de corrélation.
1.2 Formatage des données et création des agrégations

Nous disposons donc de deux matrices de paramètres : exploitations et producteurs. Elles
possèdent chacune 317187 lignes (c’est à dire le nombre de fermes du pays) et leur nombre de
colonne est respectivement 24 et 10. (Et non pas 18 et 7, car aux paramètres en tant que tels
s’ajoutent l’identifiant de la ferme, le code de village, d’autres champs de localisation et
parfois des colonnes doublons).
Nous allons décrire point par point les opérations effectuées avec Scilab sur ces données pour
aboutir aux données agrégées de la population et à leur analyse.
• remarques préalables :
Nous avons adopté le choix d’utiliser des matrices sous forme de fichiers textes plutôt que
sous forme de fichiers codés, moins coûteux en espace mais non lisibles directement.
C’est pourquoi nous utilisons les fonctions fscanfmat et fprintfmat : lecture et écriture de
matrices en mode texte.
Pour être lisibles par Scilab nous avons enlevé l’entête du fichier d’origine et mis des espaces
comme séparateurs de données.
On trouvera dans l’annexe 1 le code source des algorithmes les plus représentatifs pour
chacun des points développés ci après.
A. Obtention des codes municipalité et département
Il faut avant tout récupérer pour chaque ferme son numéro de département et de municipalité,
c’est à dire les deux échelles sur lesquelles porteront la majorité des agrégations. Pour cela,
nous utilisons la fonction floor pour tronquer de manière entière le code village de manière
entière :
Code département = floor (code village/10000) ;
Code municipalité = floor (code village/100) ;
26
Notons ici qu’une erreur de zéro s’est glissée dans l’e-mail qui nous informait de ces
coefficients de division : Et pour obtenir les codes municipalités nous avons divisé par 1000
au lieu de 100…
Et comme nous ne devions voir la personne qui nous a fourni les données que deux mois plus
tard, nous avons fait toute notre analyse de données avec cette erreur :
Au final nous avions 38 municipalités au lieu de 290, et les données agrégées en découlant
n’avaient évidemment aucun utilité réelle.
Heureusement ceci n’a eu que peu de préjudices pour la suite de nos travaux, si ce n’est
d’empêcher la possibilité de trouver des corrélations valables entre paramètres à ce niveau
d’agrégation.
B. Création des données agrégées (sommes et variances) à chaque niveau

d’agrégation pour les données d’exploitation.
Les paramètres d’exploitation sont des données quantitatives (surfaces). Nous avons donc
agrégé chaque paramètre, district par district, pour chacune des échelles.
De plus nous avons ajouté une colonne au fichier résultat, contenant la somme des fermes
contenues dans chaque district.
Ceci constitue donc les données agrégées sous forme de sommes.
Nous avons aussi agrégé les variances de chaque paramètre, en utilisant cette fois la fonction
Corr au lieu de faire une simple somme des valeurs.
Puis nous avons séparé cette matrice en autant de fichiers que de colonnes, pour une plus
grande facilité d’utilisation de ces données, qui seront traitées sous Excel.
C. Visualisation des données par classes de superficie : (au niveau global,

départemental et municipal) et par déciles
Pour avoir un aperçu général des données, nous avons sélectionné des paramètres
représentatifs, tels que la surface totale des exploitations, et les avons agrégé selon des classes
définies.
Pour les surfaces, les intervalles de classe ont été choisis d’ordre exponentiel car le Honduras,
comme de nombreux pays d’Amérique latine, possède une grande disparité agricole : D’un
coté des milliers de fermes de moins d’un hectare, de l’autre quelques immenses exploitations
de plus de 10000 hectares, avec tous les intermédiaires entre les deux.
Nous avons également refait ce classement par la méthode des quantiles (déciles plus
exactement) qui est plus parlante dans ce cas.
D. Agrégation des paramètres pour les données des producteurs.
Ces paramètres sont d’ordre qualitatif : il y a des variables binaires, comme le sexe (bien qu’il
y ait toujours en plus un champ supplémentaire : « non renseigné ») et des variables de
classes comme le niveau d’études. Même l’age peut être considéré comme une variable de
classe car le champ « 99 » ne signifie pas « 99 ans » mais « non renseigné ».
27
Mais pour ce paramètre âge on choisira des intervalles de classe adaptés : par tranche de 10
ans plutôt que année par année.
Les données agrégées des producteurs seront donc toutes organisées par classes : on séparera
donc chaque fichier colonne (contenant les données pour un paramètre) en autant de fichiers
que de classes contenues dans le paramètre.
E. Agrégation des 2 matrices : producteurs et exploitations
Pour pouvoir rentrer tous les paramètres en même temps dans le programme nous allons
agréger les 2 matrices de données
Scilab réalise très facilement et très rapidement cette fonction. (Syntaxe : z = [x y])
Auparavant nous avons dû trier chacune des matrices par ordre croissant de l’identifiant. Ceci
grâce à la fonction gsort, également très rapide (car c’est une fonction interne de Scilab ; si
nous avions du créer une routine de tri à l’aide d’une boucle « for… », l’exécution de
l’algorithme aurait été beaucoup plus longue).
Notons d’ailleurs ici que pour optimiser un algorithme utilisant de telles matrices, on peut agir
à deux endroits :
- S’assurer que la matrice est entièrement en mémoire, pour limiter les accès
disque,
- limiter le nombre de passages en revue de cette matrice avec des boucles
« for », « while »…
F. formatage des fichiers pour le programme
Le programme demandera un certain formatage pour le fichier d’entrée. Il y aura en fait trois
fichiers, pour plus de souplesse :
• Infopop.txt : Ce premier fichier contiendra les informations globales de la
population : reprise de l’entête du fichier initial avec noms des paramètres, types de
variables et catégories, ainsi que des informations sur les différentes échelles utilisées.
• codevillage.txt : Ce fichier contiendra les codes de village de chaque ferme. Ce champ
a été extrait de la matrice principale pour plus alléger les accès mémoire.
• matpop.txt : C’est la matrice globale sans les entêtes. Il contient tous les paramètres
de toutes les fermes, séparés par un caractère défini (ici : une virgule).
1.3 Etude des corrélations entre paramètres

Nous avons ensuite étudié les corrélations entre les paramètres de la population dans le but de
déterminer ceux qui seront utilisés par l’application au niveau de l’algorithme de
minimisation quadratique, c’est à dire ceux à partir desquels on va créer les contraintes pour
la population à générer.
En effet, il serait inutile et coûteux en termes de mémoire et de temps de définir des
contraintes provenant de deux paramètres très corrélés car les prototypes générés auraient le
même profil si on prenait en compte un seul paramètre.
28
Quant aux paramètres non utilisés, ils serviront pour la validation : On vérifiera ainsi que les
données agrégées de la population initiale et celles de la population générée sont semblables
pour ces paramètres (qui ne sont pas intervenus dans le processus de recréation).
Nous avons calculé la corrélation de toutes les combinaisons de paramètres pris deux à deux
car même si certains couples n’ont pas de sens, on est sur de ne pas passer ceux qui
pourraient se révéler intéressants.
Faute de temps nous nous sommes limités à traiter les corrélations pour les données
quantitatives mais pas pour les données qualitatives (Données des producteurs) : pour
exploiter ces dernières, il aurait fallu transformer les variables qualitatives en variables
binaires.
L’algorithme en Scilab pour le calcul des corrélations se situe à l’annexe 1.G

Nous obtenons le coefficient de corrélation par la formule :
Coefficient de corrélation = Covariance / produit des Ecarts Types des 2 séries de données
La fonction Scilab corr permettant d’obtenir la covariance.
Notons ici une source d’erreur possible : Scilab n’utilise pas les variances (écarts types au
carré) de la même façon qu’Excel pour le calcul du coefficient de corrélation.
En effet Excel utilise la variance calculée pour une population : (fonction var.p) de
formule :
Alors que Scilab utilise la variance d’un échantillon,

de formule :
1.4 Résultats
Les résultats de l’analyse de données sont présentés dans l’annexe 2.
Nous avons omis les diagrammes qui portaient sur les municipalités car comme nous l’avons
vus, ils se sont révélés faux. Et le temps nous à manqué pour les refaire.
Malheureusement les corrélations ont été faites entièrement au niveau des municipalités, nous
ne pouvons donc rien en tirer si ce n’est qu’elles ont montré que sur des données trop
disparates, comme les surfaces des fermes, les corrélations sont biaisées. ( Il y avait par
exemple une zone avec une ferme de plus de 13000 ha ! cette disproportion augmentait
artificiellement le coefficient de corrélation).
29
2. Conception de l’application
2.1 Structure globale
Le programme a été conçu sous Jbuilder 3.5.
L’interface utilise uniquement des composants swing.
Nous nous sommes assurés que le code soit vide de toute classe sous licence Jbuilder (par
exemple le VerticalFlowLayout : classe servant à disposer facilement des objets graphiques
alignés verticalement).
Les classes sont regroupées dans un package portant le nom de JStatBox, qui est également le
nom de l’application.
Le programme démarre à partir d’une classe Main qui appelle une classe Interface. Celle-ci
appellera à son tour les classes des différents modules, au fur et à mesure qu’ils sont requis
par l’utilisateur. Fondamentalement les classes principales sont indépendantes de l’interface
graphique. Mais on ne peut pas les faire fonctionner de façon autonome pour autant (mode
Batch) car certaines opérations de l’utilisateur ne sont possibles que par l’intermédiaire de
l’interface (du moins pour l’instant).
Nous allons décrire l’application module par module, en partant d’une vision globale par
l’approche UML pour décrire ensuite les attributs et méthodes clés des classes de chaque
module.
Le programme n’étant pas terminé à l’heure où nous écrivons, nous nous concentrerons
principalement sur le module Population et sur l’interface.
2.2 Le module population

C’est le module qui se charge de lire les données d’entrée, de les traiter pour qu’elles soient
facilement utilisables par les autres modules, en les mémorisant sous forme d’arborescence de
fichiers grâce à la classe Echelle
Voyons sa structure sous forme de diagramme en modélisation UML (nous ne faisons

apparaître que les méthodes les plus importantes, les méthodes d’accès aux données privées
sont ignorées) :
30
Diagramme de classe du module Population
Les classes prototype et agrégation ont des relations de composition vis à vis de la classe
Population, tandis pour les objets Echelle et ChoixAgreg , il n’y a qu’une seule instance de
chaque par classe Population.
Nous allons d’abord voir la classe Population puis voir ensuite les classes qui lui sont
subordonnées.
1) Classe Population
La classe Population est l’objet qui va contenir toutes les données concernant une population
étudiée :
Attributs :
Vector vpop : vecteur contenant tous les prototypes (objets prototypes) de la population
étudiée.
Vector vagreg : vecteur contenant toutes les données agrégées calculées (objets Agreg) de
la population étudiée
char sep : le caractère de séparation des données de la matrice globale.
31
Vector ventete : vecteur contenant le nom de chaque paramètre.
Vector vcategorie : vecteur contenant la catégorie (exploitation, producteur ou production)

de chaque paramètre.
Vector vtype : vecteur contenant le type (float, int, boolean…) de chaque paramètre.
Vector vech : vecteur contenant les noms des différentes échelles de la population.
Vector vfraction : diviseur pour l'agrégation (10000 pour dep , 100 pour mun, 1 pour village)
Vector vCodeEch : contient la liste des codes village pour chaque prototype.
ChoixAgreg choixagreg : objet contenant tout les paramètres d’agrégation et ceux qu’on aura
sélectionnés effectivement pour le calcul des données agrégées.
Echelle arbre : l’arborescence des différentes sous régions.
Vector vreference : vecteur contenant les références de chemin (sous forme d’objets File) de
tous les villages (c’est à dire la plus petite sous région de la population)
Méthodes :
public void lirefichierInfo(File data, String nom) : lecture du fichier infopop.txt
(informations sur les paramètres et les échelles de la population ) en utilisant la classe
BufferedReader.
public void lirefichierData(File data, String nom) : lecture du fichier de données matpop.txt
public void lirefichierEchelle(File data, String nom) : lecture du fichier des codes village des
prototypes codevilage.txt
public String getCodeEchelle(int idxCode, int idxEch) : méthode qui reçoit un n° de

prototype et un niveau d'échelle et qui renvoie le code d’échelle correspondant.
public void ecrirefichier(Population pop, String fsortie, char separ) : écriture de la matrice
de population dans un fichier texte en utilisant la classe BufferedWriter. Cette méthode a été
écartée au profit d’une methode plus efficace : l’écriture des données dans des répertoires
arborescents.(voir plus loin)
public void creeVreference(Vector v) : méthode qui crée les références (sous forme d’objet
File) aux différents répertoires de l’arborescence, pour un accès plus rapide.
32
2) Classe Prototype
L’objet Prototype représente un vecteur ligne de la matrice de population c'est-à-dire une

ferme avec tous ses paramètres, contenus sous forme de chaîne de caractères dans un vecteur
(vligne) : D’abord l’identifiant puis les caractéristiques du terrain, les caractéristiques de
l’exploitant et enfin les caractéristiques des productions.
Attributs :
Vector vligne : Vecteur contenant les paramètres d’un prototype, sous forme de chaînes de
caractère.
3) Classe Agreg
L’objet Agreg représente une donnée agrégée pour un paramètre donné, un outil d’agrégation
(somme, variance…) et éventuellement un paramètre de référence de classe.
Ce paramètre de référence de classe est un autre paramètre de la population à partir duquel on
peut découper le premier paramètre en un certain nombre de classes. Ceci
A cet objet Agreg correspondra un fichier agreg.txt. Donc le niveau d’échelle de l’agrégation
n’a pas besoin d’être précisé puisqu’ il est défini par l’endroit ou se situera le fichier dans
l’arborescence de répertoires.
Attributs :
String paraAgreg : nom du paramètre agrégé sous forme codée
int codeType : le type des données (elles sont traitées différemment si elles sont
quantitatives ou qualitatives).
int refProto : le numéro de paramètre sur lequel porte les données agrégées
int nbClasses : le nombre de classes, si le paramètre a été séparé en classes. (par défaut c’est
1 si il n’y a pas de découpage).
int refClasseProto : le numéro de paramètre utilisé comme référence pour le découpage en

classes.
int[] tabBorne : tableau des intervalles de classes.
int[] tabData : tableau des données agrégées pour chaque classe (de même taille que
tabBorne)
4) Classe échelle
33
Le but de cet objet est la création d’une arborescence de répertoires qui reprendra la structure
imbriquée des différentes sous régions du pays étudié. Chaque répertoire (ou nœud de l’arbre)
correspondra à un district (département, municipalité, village…) et contiendra un fichier
d’informations. Ensuite viendront s’ajouter dans les répertoires de la dernière échelle (ici les
villages) des fichiers contenant les données des prototypes de ces nœuds (village) en question.
On transforme donc la grande matrice de population en une série de petits fichiers auxquels
on accède lorsque l’on en a besoin, plutôt que de charger en mémoire la matrice globale dans
son ensemble.
Ensuite, on n’utilisera plus que cette structure en arbre que l’on pourra charger au démarrage
de l’application et abandonner l’usage de la matrice globale.
L ‘arbre est en fait une liste chaînée d’objets Echelle. Une méthode récursive crée un nœud et
remplit ses descendants (sous régions de ce nœud) avec cette même méthode (appel récursif),
jusqu’à atteindre la limite d’échelles.
La construction de l’arbre se fait par parcours en profondeur des différentes échelles, pour
n’avoir qu’un seul parcours de la matrice de population globale. Un parcours en largeur aurait
pris beaucoup plus de temps.
Attributs :
Vector vfils : tableau contenant la liste des objets échelle successeurs de l'objet Echelle
courant
String nomEchelle : nom d’échelle du nœud : "dep" si l'objet Echelle est un département
int niveau : code correspondant au niveau d’échelle. "1" si l'objet Echelle est un
département.
String code : numéro de district
int nbSousNiveau : taille du vecteur vechelonLocal, c’est à dire le nombre de descendants

du nœud.
Vector vechelonLocal : tableau des informations (sous forme d’objets InfoNoeud)

de chaque échelon contenu dans l'objet échelle courant.
File ref : référence de chemin de l’objet échelle (ex: global\dep_1\)
Méthodes :
Echelle creerArbre (Population pop) : méthode qui initialise la création de l’arbre.
void remplir(Population pop, int numProto, Echelle pere, int niveauCourant) : méthode
récursive qui crée un nœud de l’arbre et le remplit de ses descendants en s’appelant elle
même.
void writeArbre(Echelle arb, File repPater, String repfils) : méthode qui crée les repertoires
pour chaque nœud de l’arbre et y ajoute des fichiers d’information.
34
void ecrireVpoptoProto(Population pop) méthode qui écrit dans des fichiers séparés (et qui
les placent dans l’arborescence) les données de chaque village.
5) Classe Infonoeud
Cette classe contient diverses informations pour chaque nœud de l’arborescence.
Attributs :
String nom : nom du nœud (département, municipalité, village…)
float superficie : somme des superficies des fermes contenues dans le nœud et ses
descendants.
int nbProto : nombre de fermes(producteurs) contenu dans le nœud et ses descendants.
6) Classe ChoixAgreg
Paramètres de population, outils d’agrégation et échelles peuvent varier d’une étude de cas à
l’autre Ils doivent donc être définis sous formes dynamiques : on utilise donc des vecteurs
pour les stocker. De même pour les 3 vecteurs qui leurs sont associés et qui stockent les choix
de l’utilisateur pour l’agrégation.
Attributs :
Vector vNomParam : vecteur contenant la liste ordonnée des noms de paramètres affichés
dans l’onglet Statistiques
Vector vChoixParam : vecteur contenant true ou false selon les paramètres choisis pour
l’agrégation.
Vector vNomEchelle : vecteur contenant la liste ordonnée des noms d’échelle affichés dans
l’onglet Statistiques
Vector vChoixEchelle : vecteur contenant true ou false selon les échelles choisies pour
l’agrégation.
Vector vNomOutil : vecteur contenant la liste ordonnée des noms d’outils affichés dans
l’onglet Statistiques
Vector vChoixOutil : vecteur contenant true ou false selon les outils choisis pour
l’agrégation.
Méthodes :
35
void creervListeAgreg(Population pop,String sEchelle) : méthode générale qui appelle les 3
suivantes :
void creervNomEchelle(pop,sEchelle) : méthode qui crée le vecteur vNomEchelle et qui
initialise le vecteur vChoixEchelle à zéro.
void creervNomParam(pop) : méthode qui crée le vecteur vNomParam et qui initialise le

vecteur vChoixParam à zéro.
void creervNomOutil() : méthode qui crée le vecteur vNomOutil et qui initialise le vecteur
vChoixOutil à zéro.
2.3 Le module statistiques

Le module de statistiques a pour but de fournir des méthodes pour créer les données
agrégées à partir des trois types de paramètres que l’utilisateur aura choisi:
Echelles, Paramètres de la population et outils d’agrégation.
Par outil d’agrégation nous entendons : somme, variance, écart type, quantiles, voire fonctions
plus élaborées par la suite.
Ce module est en cours de codage à l’heure où nous écrivons.
2.4 Le module optimisation

Il comprend les deux algorithmes que nous avons présenté antérieurement :
• L’algorithme de minimisation quadratique provenant de « R ». La classe d’appel est
créée et fonctionnelle mais non encore implémentée dans le programme.
• l’algorithme de type génétique (SA2 : recuit simulé) n’est pas encore créé.
2.5 L’interface
L’interface dispose d’une barre de menu : pour fonctions diverses dont choix de la langue
pour cela nous avons créé un « Ressource Bundle » : organisation des chaînes de caractères
sur des fichiers différents pour chaque langue, ensuite on choisit quel fichier charger pour
avoir la langue voulue.
On voit ensuite un onglet pour chaque module. Pour l’instant ne sont terminés que les onglets
population et statistiques. Puis viendrons s’ajouter les onglets Minimisation, et Visualisation
qui correspondent aux modules correspondants.
Voyons un aperçu de l’onglet population (page suivante) :

A gauche : la liste des paramètres lorsque la population est chargée.
36
Au milieu : les boutons de lecture et d’écriture de la matrice de population et de l’arbre
d ‘échelles.
Lorsque la population n’est pas chargée, les autres onglets sont inaccessibles, de même que
les boutons qui font références à la population chargée.
La fenêtre principale avec l’onglet population
Voyons à présent un aperçu de l’onglet Statistiques (page suivante) :

Il est constitué de trois panneaux contenant des boutons à cocher créés dynamiquement.
Ces panneaux correspondent aux paramètres à définir pour calculer les données agrégées
(Paramètres de population, Echelles, Outils).
A droite une liste de boutons permettant de lancer ,de réinitialiser le processus de création des
données agrégées, et de sauver celles ci.
37
La fenêtre principale avec l’onglet Statistiques
38
V. Conclusion
Bilan
Ce vaste projet est terminé en ce qui concerne la partie analyse de données mais ne l’est pas
pour l’application.
Au final les résultats de l’analyse de données se révèlent mitigés au niveau de leur qualité, à
cause notamment d’une simple erreur de zéro qui a eu de fâcheuses conséquences.
Nous avons également entrevu la difficulté de trouver des tests statistiques convenant le
mieux aux différents cas, c’est à dire capables de faire « parler » les données.
Et puis nous regrettons de n’avoir pu disposer des données de production, certainement très
riches en information.
Quoi qu’il en soit cette première partie du stage a rempli parfaitement son rôle de découverte
des méthodes de reconstruction de population et de préparation nécessaire à la deuxième
partie.
En ce qui concerne l’application, il reste beaucoup a faire. Un certain retard a été pris lorsque
nous avons travaillé sur la structure de l’objet Echelle, qui demandait une structure
parfaitement optimisée pour satisfaire les limitations en mémoire du programme. Beaucoup
de temps à également été passé au début de la phase de code, car la programmation objet
demande une certaine « mécanique de pensée » qui ne s’acquiert qu’avec une pratique
intensive.
En ce qui nous concerne, ce stage a été doublement bénéfique puisqu’il nous a fait pratiquer
de nombreuses techniques statistiques et fait découvrir toute la conception d’un projet
informatique, depuis la formalisation UML jusqu’au codage en langage objet.
39
Perspectives
D’ici la fin de notre stage, il faudra tout d’abord terminer le noyau de base du programme :
C'est-à-dire le module Statistiques et le module Minimisation avec ses deux algorithmes de
minimisation.
Puis de nombreuses améliorations seront à faire, dans le souci d’assurer une bonne succession
du code pour la ou les personnes qui prendront le relais du développement ( ce sera à priori
essentiellement notre maître de stage) Et il y a également le souci de fournir un outil
documenté et facile d’accès aux destinataires du programme.
Ainsi, nous prévoyons de :
- Documenter les classes en HTML (avec javadoc)
- Ecrire un mode d’emploi
- terminer la localisation en anglais et en espagnol.
Puis plus tard pourront être réalisés :

- le module visualisation des données.
- l’implémentation d’outils statistiques évoluées dans module statistiques.
- la création d’un module permettant de sauver et charger des plans d’expérience.
Ce projet est un point de départ. On peux déjà imaginer la possibilité d’y greffer des modules
dont les objectifs serviraient un autre domaine, mais qui utiliseraient les structures et outils de
cette application.
40
Références bibliographiques
Williamson P., Birkin M., Rees P. H. 1998, “The estimation of population microdata by using
data from small area statistics and samples of anonymised records”. Environment and
planning A 30 785-816.
Charlton J. 1998, “Use of the Census Samples of anonymised Records (SARs) and survey
data in combination to obtain estimates at local authority level”. Environment and planning A
30 775-784.
Goldfarb D., Idnani A. 1983, “A numerically stable dual method for solving strictly convex
quadratic programs”. Mathematical programming 27 1-33.
41
ANNEXES
Annexe 1 : code source en langage Scilab des algorithmes utilisés lors de

l’analyse de données.
1.A. Création des listes de code : département et municipalité
a2=fscanfMat('caract_explot_col2.txt'); //lecture de la colonne

« codes_villages »
d=floor(a2/100); //creation matrice municipalité
fprintfMat('codemun.txt',d,'%4.0f'); //sauvegarde du fichier
e=floor(a2/10000); //creation matrice department

fprintfMat('deptcode.txt',e,'%4.0f');
1.B. Création des données agrégées au niveau municipalité
Sommes :
chdir('C:\mesdocs\data') //répertoire de travail

stacksize(40000000); //augmentation de la taille de la pile mémoire
b=fscanfMat('matb.txt');
n=size(b ,'r') //nombre de lignes

lmax=size(b,'c') +1; //nombre de paramètres
dep=fscanfMat('codemun.txt'); // (ou deptcode)

imax=max(dep);
matdep=zeros(imax,lmax); //matrice des données agrégées
for j=1:n,
i=dep(j,1);
for l=1:lmax-1,
matdep(i,l+1)= matdep(i,l+1)+ b(j,l); //on agrege les données
end;
matdep(i,1)=matdep(i,1)+1; //on fait la somme du nombre de fermes
end;
fprintfMat('matmun.txt',matdep);
Variances agrégées:
//***********************Algo Variance mun ***************************
42
b=fscanfMat('matg.txt');
m=size(b,'c')
n=size(b,'r')
h=fscanfMat('sep.txt');
niv=38;
matvar=zeros(m,niv);
legende=zeros(m,niv);
cpt=0;
for i=1:niv, // mun par mun

cpt=cpt+1;
for j=1:m, //param par param
[cova,moy]=corr(b((h(cpt,1)+1):h(cpt+1,1),j),b((h(cpt,1)+1):h(cpt+1,1),j),1); //
variance (covariance entre une série de données et elle même)
matvar(j,i)=cova;
legende(j,i)=j;
end;
end;
fprintfMat('legendevar.txt',legende);
fprintfMat('matVarMun.txt',matvar);
for i=1:38,
i
fprintfMat(strcat(['matvarMun_' stripblanks(string(i)) '.txt']),matvar(:,i));
//fprintfMat(strcat(['legCorMun_' stripblanks(string(i)) '.txt']),legende(:,i));
end;
Puis nous séparons la matrice résultat en autant de fichiers que de paramètres (colonnes) :
for i=1:11,
i
fprintfMat(strcat(['matdep_' stripblanks(string(i-1)) '.txt']),matdep(:,i)); //formatage
du nom de fichier
end;
1.C. Classement des surfaces totales des exploitations (colonne 13) selon une échelle de
valeurs exponentielles.
//*****************************Algo classes de superficie par dept********

dep=fscanfMat('deptcode.txt');
s=fscanfMat('caract_explot_col13.txt'); //on lit le paramètre surface totale
n=size(dep ,'r')
43
imax=max(dep);
matdep=zeros(imax,11);
for i=1:n,
j=dep(i,1);
matdep(j,1)= matdep(j,1)+1;
if s(i,1)<1 , // sélection de la classe de superficie

matdep(j,2)=matdep(j,2)+1;
end;
if s(i,1)>=1 & s(i,1)<5 ,
end;
if s(i,1)>=5 & s(i,1)<10 ,
end;
if s(i,1)>=10 & s(i,1)<50 ,
end;
if s(i,1)>=50 & s(i,1)<100 ,
end;
if s(i,1)>=100 & s(i,1)<500,
end;
if s(i,1)>=500 & s(i,1)<1000,
end;
if s(i,1)>=1000 & s(i,1)<5000,
end;
if s(i,1)>=5000 & s(i,1)<10000,
end;
if s(i,1)>=10000 ,
end;
end;
Classement des surfaces totales des exploitations (colonne 13) en déciles :
//*****************************Algo Déciles par MUNICIPALITE********
//dep=fscanfMat('codemun.txt');
s=fscanfMat('caract_explot_col13.txt'); //on lit le paramètre surface
decile=zeros(10,1); //tableau contenant les bornes des déciles
n =size(s ,'r');
[mats,k]=gsort(s,'r','i'); //on trie les surfaces par ordre croissant

r=zeros(11,1); //tableau contenant le nombre de fermes par classe
pas=round(n*10/100) //le pas est arrondi en entier
for u=1:10
decile(u,1)=pas*u;
44
end;
decile(10,1)=n;
r(1)=mats(1,1);
for i=2:11,
r(i)=mats(decile(i-1),1);
end;
fprintfMat('decile.txt',decile);
fprintfMat('bornedecile.txt',r);
1.D. Agrégation du paramètre age (matrice des caractéristiques des producteurs) :
//**********************Algo agreg Producteurs par dep*********************
b=fscanfMat('caract_produc_col8.txt');
n=size(b ,'r')
dep=fscanfMat('deptcodeP.txt');
imax=max(dep);
matdep=zeros(imax,12);
for j=1:n,
i=dep(j,1);
matdep(i,1)=matdep(i,1)+1;
if b(j,1)<10, //on sépare en 10 classes d’âge

end;
if b(j,1)>=10 & b(j,1)<20,
end;
if b(j,1)>=20 & b(j,1)<30,
end;
if b(j,1)>=30 & b(j,1)<40,
end;
if b(j,1)>=40 & b(j,1)<50,
end;
if b(j,1)>=50 & b(j,1)<60,
end;
if b(j,1)>=60 & b(j,1)<70,
end;
if b(j,1)>=70 & b(j,1)<80,
end;
45
if b(j,1)>=80 & b(j,1)<90,
end;
if b(j,1)>=90 & b(j,1)<=98,
end;
if b(j,1)=99, //99 = champ non renseigné

end;
end;
//fin
1.E. Tri et agrégation des matrices Exploitations et Producteurs
//*********************tri matrice exploitations et producteurs********
c=fscanfMat('matc.txt'); //***tri matrice producteurs

n=size(c ,'r')
[matz,k]=gsort(c(:,1),'r','i');
matd=c(k,:); //**********fonction de tri selon k
fprintfMat('matd.txt',matd);
c=fscanfMat('matb.txt'); //**tri matrice exploitations

n=size(c ,'r')
[matz,k]=gsort(c(:,1),'r','i');
mate=c(k,:);
fprintfMat('matbTriée.txt',mate);
//****agrégation des 2 matrices*********
matbtri=fscanfMat('matbtri.txt'); //** on lit matrice exploitations triée

matd=fscanfMat('matd.txt'); //** on lit matrice producteurs triée
g=[matbtri matd]; //agregation

fprintfMat('matg.txt',g);
1.F Ecriture du fichier matpop.txt
g=fscanfMat('matg.txt');
h=[g(:,1:24) g(:,28:34)];
fprintfMat('matjava.txt',h,',%.3f'); //écriture formatée, séparateur : ‘,’
1.G Calcul des corrélations entre les paramètres, au niveau des municipalités.
//*************Algorithme Corrélation municipalités *********************
m=size(b,'c')
n=size(b,'r')
46
niv=38;
h=fscanfMat('codemun3.txt'); //vecteur pour les tailles des matrices r
//*******création matrice sep (séparation) : contient les lignes ou il y a changement de

municipalité
cpt=1;
d=floor(b(:,2)/1000);
sep=zeros[40,1];
sep(1,1)=1;
for i= 1:n,
if i>1,
if d(i) ~= d(i-1),
cpt=cpt + 1;
sep(cpt,1)=i;
end;
end;
if i=n,
cpt=cpt + 1;
sep(cpt,1)=i;
end;
end;
//*********calcul des corrélations
m=size(b,'c')
n=size(b,'r')
h=fscanfMat('sep.txt');
niv=38;
matcor=zeros(m*m,niv); //matrice contenant les coeff de corrélation
legende=zeros(m*m,niv); // matrice mémorisant les noms des municipalités
correspondant aux coefficients.
cpt=0;
for i=1:niv, // municipalité par municipalité

cpt=cpt+1;
pas=0;
for j=1:m, //paramètre par paramètre

for k=j:m,
pas=pas+1;
[cova,moy]=corr(b((h(cpt,1)+1):h(cpt+1,1),j),b((h(cpt,1)+1):h(cpt+1,1),k),1);
//covariance
taille=h(cpt+1,1)-h(cpt,1); //taille d’une municipalité
y=(st_deviation(b((h(cpt,1)+1):h(cpt+1,1),j),'r'))*(sqrt((taille-1)*taille)/taille);//ecart type
1
47
z=(st_deviation(b((h(cpt,1)+1):h(cpt+1,1),k),'r'))*(sqrt((taille-1)*taille)/taille);
//ecart type 2
correl=cova/(y*z);
matcor(pas,i)=correl;
legende(pas,i)=j+(k/100);
end;
end;
end;
//écriture des matrices

fprintfMat('legende.txt',legende);
fprintfMat('matCorMun.txt',matcor);
for i=1:1,
i
//fprintfMat(strcat(['matCorMun_' stripblanks(string(i)) '.txt']),matcor(:,i));
fprintfMat(strcat(['legCorMun_' stripblanks(string(i)) '.txt']),legende(:,i));
end;
48
Annexe 2 : Extraits des résultats de l’analyse de données.
Analyse des données

Pour les caractéristiques des exploitations et des producteurs
1) Données Générales
Nombre de fermes par dept
30000
25000
Nb fermes
20000
15000
10000
5000
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
code département
Le nombre de fermes est très variable d’un département à l’autre (pour la plupart il y en a de
10000 à 25000). On note également de très faibles effectifs : le département 9 avec 3800
fermes et surtout le département 11 avec un peu plus de 300 fermes. C’est dans ce dernier que
l’on notera plus tard de grandes différences avec les autres départements dans l’analyse des
différents paramètres.
nb fermes par village
1600
1400
1200
nb fermes
1000
800
600
400
200
0
10101
10416
10733
20201
20825
30134
32116
40419
40914
41310
50602
50910
60107
60515
61402
70319
71002
71536
80303
81108
90111
31009
31505
42114
50204
82002
2E+05
2E+05
1E+05
1E+05
1E+05
1E+05
1E+05
1E+05
1E+05
1E+05
1E+05
2E+05
2E+05
2E+05
2E+05
2E+05
2E+05
2E+05
2E+05
2E+05
2E+05
2E+05
aldea
Au niveau village, la variabilité devient beaucoup plus importante : les villages vont d’une
seule ferme à 1391.(moyenne : 84 , variance : 7818).
49
2) Analyse des Exploitations (surfaces)
Surfaces totales :
surface moyenne des exploitations par dept
25,00
Surface moyenne (Ha)
20,00
15,00
10,00
5,00
0,00
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
Departements
surface totale des fermes par dept
600000,00
Surface totale (Ha)
500000,00
400000,00
300000,00
200000,00
100000,00
0,00
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
code département
Ces graphiques ne permettent pas de voir si il y a des zones de fermes de même taille.
(ex : municipalité contenant une majorité de grandes fermes). On va donc séparer les tailles de
fermes en classes de superficie (voir plus loin).
Répartition de la taille des fermes suivant la méthode des déciles :
% de fermes
Intervalles : surface dans
totale (Ha) l’intervalle
0 0,068 0
0,068 0,616 10
0,616 0,685 10
0,685 1,027 10
1,027 1,37 10
1,37 2,055 10
2,055 2,74 10
2,74 4,658 10
4,658 8,219 10
8,219 19,863 10
19,863 13461,644 10
100
50
Corrélations entre fermes de grande et de petite taille :
Correlation grandes (>100 ha) et
petites fermes (<1 ha)
par departement
1200
nb fermes de surface >100 ha
1000
800
600
400
200
0
0 2000 4000 6000 8000 10000
nb fermes de surface<1 ha
Correlation grandes (>1000 ha) et

petites fermes (<1 ha)
par departement
nb fermes de surface >1000 ha
20
15
10
0
0 2000 4000 6000 8000 10000
nb fermes de surface<1 ha
On ne voit pas de corrélation évidente : le fait qu’il y ait de grandes ou très grandes fermes
n’empêche pas la présence de fermes de petite taille : ceci est confirmé par le graphique
suivant : Répartitiondes tailles de fermes selondes classes (Ha) par département
100%
10000 et +
5000 à 10000
80%
1000 à 5000
surface (Ha)
500 à 1000
60%
100 à 500
50 à 100
40%
10 à 50
5 à 10
20%
1 à5
0% 0 à1
0
8
1
9
1
Code département
51
On voit qu’il n’y a pas de fortes différences entre les municipalités : toutes contiennent des
fermes de tailles variées en proportions comparables (sauf pour les fermes de très grande taille
qui sont rares et plutôt dispersées parmi les municipalités).
On note cependant pour le département 15 une proportion plus faible de fermes de 0 à 1 Ha
au profit de fermes plus grandes (10 à 50 mais aussi 50 à 100).
a) Propriété des terres

100%
Propriétés des terres
Par DEPT
80% pourcentage des
surfaces occupées
60% E10F(dadas...)
E10E(autres locations ?)
40% E10D (loué ?)

E10C (ejidales)
E10B (terres nationales)
20%
E10A (terres propres)
0%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
On voit de grandes variations pour les classes « terres personnelles » « terres nationales » et
« ejidales » (les 3 classes les plus représentées).
Par exemple le département 9 contient une majorité de terres nationales.
Le département 15 qui possède également une part importante de terres nationales.

(Corrélation possible avec le fait que ce département comporte beaucoup de fermes de grande
taille).
b) Usage des terres
52
Usage de la terre POURCENTAGES par dept
100%
90% otros usos no agropec

80% otros usos agropec
70%
avecplans d'eau...
60%
avec bois
50%
avec paturages cultivés
40%
avec paturages naturels
30%
repos de - d'1 an
20%
Guamil:repos de + d '1 an
10%
permanentes
0%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 annuelles
Ici on observe beaucoup de variabilité, pour presque tous les paramètres, mais on ne
distingue pas de corrélation particulière.
Les terres semblent avoir un usage agricole similaire dans toutes les régions. On notera
cependant la concentration de « plans d’eau » dans le département 6 (lac … ?)
3) Analyse des données des producteurs
a) Condition juridique
Condition juridique des exploitations par département

100%
80% Autres
% de fermes
60% Gouvernement
SOCIED -COO - COMER
40% EMP-COOP - ASEN -RE
ferme individuelle
20%
0%
1
11
13
15
17
Code dept
Correlation grandes fermes (>100 Ha) et propriétés
collectives-gouvernementales
par mun
700
La quasi-totalité
600 des fermes sont individuelles. Ceci explique la forte corrélation de ce
paramètre avec500la surface totale.
400
>100
300
200
100
0
0 50 100 150 200
prop collectives
53
On ne pas conclure de corrélation évidente grandes fermes - propriétés non individuelles.
b) Age du producteur
Distribution des ages (niveau global)
80000
70000
60000
50000
40000
30000
20000
10000
0
10--19 20-29 30-39 40-49 50-59 60-69 70-79 80-89 90-98
Distribution des ages (niveau dep)

99 (NR)
100% 90-98
80-89
80% 70-79
60%
60-69
50-59
40% 40-49
30-39
20%
20-29
0% sexe des producteurs selon dept 10--19
1
13
15
17
11
100%
<10 (NR)
80%
Pas de différence60%
fondamentale de classes d’âge entre les
NRdifférentes municipalités (à part le
% de fermes
département 11 : faible pourcentage de 20-29 ans) femmes

40% hommes
20%
c) Sexe du producteur
0%
13
1
11
15
17
code dept
54
Il y a à priori peu de variations de sexes entre départements : environ 10% de femmes sauf
dans le département 9 ou il y en a presque 30% .
d) Alphabétisation
producteurs sachant lire et ecrire par dept

100%
80%
% de fermes
60%
NR
40% non
oui
20%
0%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
code dept
Alphabétisation : 50 à 60 % en moyenne sauf département 11 : plus de 90% (mais c’est un

département de très petite taille : effet d’une variance plus élevée ?).
e) Niveau d’études atteint et niveau d’études validé
55
Le niveau d’études se situe pour tous les départements entre « aucun » et « primaire » avec un
pourcentage similaire (sauf pour département 11 : peut être à cause de sa taille).
niveau d'etudes atteint (par dept)
100%
80%
NR
% de fermes
60% supérieur
secondaire
40% primaire
Aucun
20%
0%
11
13
15
17
1
code dept
ultime niveau d'etudes validé (par dept)
100%
80%
aucun ou NR ?
% de fermes
60%
supérieur
secondaire
40%
primaire
20%
0%
1
11
13
15
17
code dept
56

Bourion 2002

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Bourion 2002

Uploaded by

Copyright:

Available Formats

Institut Spécialisé de Technologie Appliquée Hay Hassani

ISTA HAY HASSANI

Lieu du stage : 5, et 7 Impasse Rue Mohamed BAHI

Effectué du… au…. (nombre de mois)

Le CIAT (Centre International de l’Agriculture Tropicale) a développé des partenariats avec

Le LISC, au cours de précédents travaux (projet européen IMAGES), a commencé à

1.1 Ses Activités

Figure 1 : Activités du CEMAGREF

- le fonctionnement des hydrosystèmes,

Les produits du CEMAGREF sont :

- Les publications (740 publications/an),

1.2 Ses Ressources humaines

Génie des Valorisation et

1.3 Son Budget

Le groupement de Clermont–Ferrand, l’une des 9 délégations du territoire français, est

Le CEMAGREF de Clermont-Ferrand est constitué de 3 unités de recherche, qui ont la

- DFCF : Dynamiques et Fonctions des espaces ruraux

Le rôle du LISC est d’évaluer et de développer des méthodes de modélisation de systèmes

- les modèles dynamiques distribués spatialement,

Le thème de recherche de l’unité, MAGESTYC (Modèles pour l’Aide à la GESTion des

1. Origine et contexte du stage

Le CIAT a donc développé un partenariat avec le LISC, du CEMAGRF de Clermont-

Au fur et à mesure du déroulement du stage, de nouveaux objectifs sont apparus :

Voyons maintenant plus précisément les spécifications du programme en décrivant les

Notons qu’au début du projet, il était prévu de rechercher dans la littérature un

• Un module « plan d’expérience »

• Deuxième quinzaine d’avril à mi-juin : Analyse de données avec Scilab sur la

• Fin juin à mi-juillet : Définition de la structure du programme, Conception

• Mi-juillet à fin août : Codage du programme. Rédaction du rapport.

• Mois de septembre : codage, perfectionnement et ajout de nouveaux modules.

1.2 Microsoft EXCEL

1.3 Le langage JAVA

1.7 WinEdit 2000

2. Les méthodes de reconstruction de population

On va ensuite attribuer des coefficients (appelés λi ) à chaque prototype. Le produit des

Considérons que les paramètres de notre population P sont :

Nous noterons également Qki la quantité de k produite par l’individu i de P’.

La problème peut alors s’écrire sous cette forme :

Les variables de décision du problème sont :

Sous une autre formulation, le problème devient :

Développons maintenant ce polynôme du second degré en xi, nous obtenons :

Et nous reconnaissons la forme quadratique suivante :

où x=(xi), Q=(qij) et p=(pi) avec :

qij = 0 pour i >= j , i,j=1..n.

pi = − 1*∑ a  α n + β Q Q 

2.2 L’algorithme quadratique utilisé par l’application

Le projet « R » (www.r-project.org) est un langage et un environnement pour le calcul

L’algorithme d’optimisation quadratique de R est décrit par Goldfarb et Idnani (1983) :

2.3 Algorithmes de type génétique

Voyons un comparatif entre les deux approches, qui se révèlent complémentaires :

Approche ad hoc (analytique, spécifique) Approche génétique

Rapidité Selon solution, parfois bonne Bonne à très bonne

Performance Selon solution Bonne

Compréhension Nécessaire Non nécessaire

Applicabilité La plupart des problèmes intéressants n'ont pas Générale

1. L’approche “Hill climbing”(Ascension de colline)

Voici le déroulement de cette méthode :

c) On calcule l’effectif des contraintes observées à partir de la nouvelle population générée.

d) On calcule (ou on connaît) l’effectif des contraintes attendues de la population initiale.

e) On calcule un indicateur d’erreur appelé TAE (total des erreurs absolues) :

Voyons deux variantes de cette méthode :

HC 1 : On fait un simple remplacement de coefficients λi au hasard.

HC 2 : Le seul changement consiste, au lieu de sélectionner des coefficients λi au hasard, à

//*Algo Variance mun *****

//*********************Algo classes de superficie par dept

//*********************Algo Déciles par MUNICIPALITE

//**Algo agreg Producteurs par dep*

//*************tri matrice exploitations et producteurs