Elaboration Des CCTP

PROPOSITION DE
CAHIER DES
CLAUSES
TECHNIQUES
PARTICULIERES (C.C.T.P.)
en date du 23 novembre 2006 relatif à l’appel d’offre pour
la réalisation du lot 5 de l’inventaire national spatialisé

des émissions de polluants dans l’air
Le présent C.C.T.P. comprend 40 pages numérotées de 1 à 40 dont 2 annexes

CAHIER DES CLAUSES TECHNIQUES PARTICULIERES
« Développement de l’Inventaire National Spatialisé (INS) »
SOMMAIRE
1 Préambule................................................................................................................................. 4
1.1 Description du projet.....................................................................................................................4
1.2 Objectifs poursuivis ........................................................................................................................5
2 Documents applicables et de référence ................................................................................ 6

2.1 Documents applicables ...............................................................................................................6
2.2 Documents de référence.............................................................................................................6
3 Terminologie.............................................................................................................................. 6
3.1 Abréviations ....................................................................................................................................6
3.2 Définitions ........................................................................................................................................7
4 Objet du marché ..................................................................................................................... 7

4.1 Périmètre de la prestation............................................................................................................7
4.2 Plate-forme A..................................................................................................................................8
5 Livrables..................................................................................................................................... 9
6 Description détaillée de la prestation ................................................................................... 10

6.1 Mise en place de la plate-forme B...........................................................................................10
6.1.1 Présentation ...........................................................................................................................10
6.1.2 Les utilisateurs de la plate-forme B ....................................................................................11
6.1.3 Les fonctions de la plate-forme B ......................................................................................14
6.2 Alimentation du système PREV’AIR ..........................................................................................19
6.2.1 Le système PREV’AIR et le modèle CHIMERE...................................................................19
6.2.2 Emissions anthropiques.........................................................................................................20
6.2.3 Emissions biotiques ................................................................................................................21
6.2.4 Dépendance des émissions anthropiques et biotiques vis à vis des conditions
météorologiques ..............................................................................................................................21
6.3 Mise en uvre du site Internet de l’INS...................................................................................22
6.3.1 Navigation et Graphisme ....................................................................................................22
6.3.2 Gestion de contenu .............................................................................................................23
6.3.3 Visualisation des cartes. .......................................................................................................23
6.3.4 Gestion des scénarios ..........................................................................................................23
6.3.5 Gestion des requêtes de post traitement. .......................................................................23
6.3.6 Génération des données pré calculées ..........................................................................23
6.3.7 Autres exigences ...................................................................................................................23
6.4 Gestion de scénarios...................................................................................................................24
6.4.1 Accès aux fonctions .............................................................................................................24
6.4.2 Soumission des scénarios .....................................................................................................24
6.4.3 Outil de création des scénarios..........................................................................................25
6.5 Requêtes........................................................................................................................................26
6.5.1 Requêtes de « scénario ».....................................................................................................27
6.5.2 Requêtes de « post-traitement » ........................................................................................28
2
7 Organisation et gestion de projet .......................................................................................... 30

7.1 Description de l’équipe projet ..................................................................................................30
7.2 Planning .........................................................................................................................................30
7.3 Réunions d’avancement............................................................................................................31
7.4 Autres réunions .............................................................................................................................31
7.5 La logistique ..................................................................................................................................31
7.6 Maintenance ................................................................................................................................32
7.7 Organisation de la communication.........................................................................................32
7.7.1 Mise à disposition de la messagerie..................................................................................32
7.7.2 Journal de projet...................................................................................................................32
7.7.3 Autres.......................................................................................................................................32
8 Conditions spécifiques de réalisations .................................................................................. 33

8.1 Exigences d’architecture applicative .....................................................................................33
8.2 Développements informatiques ...............................................................................................33
8.3 Conservation des données et volumétrie...............................................................................33
8.4 Fréquentation ...............................................................................................................................34
8.5 Contraintes de service................................................................................................................34
8.6 Appropriation par l’INERIS ..........................................................................................................34
8.7 Langue de travail et des documents ......................................................................................34
8.8 Autres exigences..........................................................................................................................34
9 Modalités de recette .............................................................................................................. 35

9.1 Principes généraux d’organisation...........................................................................................35
9.2 Recette définitive de l’application et garantie.....................................................................35
10 Assurance qualité ................................................................................................................... 36

10.1 Plan d’Assurance Qualité...........................................................................................................36
10.2 Démarches qualité ......................................................................................................................36
10.3 Documentation ............................................................................................................................37
10.4 Gestion des configurations ........................................................................................................37
3
Préambule
Le projet d'Inventaire National Spatialisé (INS) des émissions de polluants atmosphériques
pour la France lancé par le Ministère de l’Ecologie et du Développement Durable (MEDD) est
destiné à répondre à plusieurs objectifs :
• contribuer à l'amélioration de la surveillance de la qualité de l'air en alimentant le
système de prévision PREV'AIR (http://www.prevair.org/fr) ;
• mettre à disposition des organismes impliqués dans des missions de service public
des données caractérisant les rejets de polluants dans l’air ;
• proposer aux différents organismes réalisant des études des ensembles de données
sur les émissions atmosphériques ;
• remplir un rôle d’information du public.
D'une résolution spatiale kilométrique et temporelle horaire, son rôle essentiel est de répondre
aux attentes des différents acteurs impliqués de manière directe ou indirecte dans
l'évaluation, l'analyse et la gestion du comportement de plus d’une vingtaine de polluants
atmosphériques émis par les différents types d’émetteurs qu’ils soient liés à des activités
anthropiques ou non anthropiques localisées en France métropolitaine et dans les
départements d'outre-mer.
Ce projet ambitieux est découpé en 5 lots attribués après appels d’offres. Les travaux en
cours correspondent aux lots 1 à 4 :
• le lot 1 relatif à la coordination du projet a été attribué à un groupement conduit
par le CITEPA en association avec ASPA, Ecole des Mines de Douai, Rémy
Bouscaren Ingénieur Conseil, et Synapse Informatique ;
• le lot 2 est en charge principalement des sources fixes et de quelques autres
sources liées à l’utilisation d’énergie. Ce lot a été confié au CITEPA et à Rémy
Bouscaren Ingénieur Conseil ;
• le lot 3 qui traite des différents modes de transports a été confié à MVA Limited en
coopération avec le CITEPA ;
• le lot 4 s’intéresse aux sources agricoles, sylvicoles et autres sources naturelles. Il a
été confié à un groupement conduit par ARIA Technologies associé à l’INRA et au
LISA.
Différents groupes techniques et un comité de pilotage sont présents au sein du projet afin
d’apporter l’expertise complémentaire aux prestataires des différents lots et valider les
solutions proposées. Au total le projet regroupe plus d’une centaine d’intervenants.
Ce document constitue le cahier des charges en vue de la réalisation du lot informatique (lot
n°5).
1.1 Description du projet

Le produit final de ce lot sera un système informatique assurant les traitements et la diffusion
des émissions de polluants atmosphériques pour la France. Les résultats et diverses données
associées seront accessibles via Internet en 2008, dans le cadre de la mise en uvre du Plan
Air rendu public en novembre 2003.
Le système sera situé sur une plate-forme informatique et mis à jour chaque année. Il
constituera progressivement un ensemble de données sur les émissions atmosphériques avec
une résolution spatiale et temporelle fine à partir de l’année 2004.
D’une manière générale, le système fournira, outre des résultats d’émissions, des informations
sur les méthodologies mises en uvre, les référentiels employés et, sous certaines conditions
4
limitant l’accès pour cause de respect des contraintes de protection des droits d’auteur et
de confidentialité, les données intermédiaires utilisées pour le calcul des émissions
(spéciation, distribution temporelle, activités, facteurs d’émission, etc.).
Le lot 5 aura en charge la réalisation des tâches informatiques comportant la mise en place
d’une plate forme ayant pour objectif :
• d’héberger l’ensemble des données nécessaires au calcul des émissions ;
• d’héberger les procédures de calcul et autres données associées (méta données) ;
• de réaliser les opérations de calcul et de formatage des résultats aussi bien en
temps réel pour les plus simples qu’en différé pour les plus complexes ;
• d’assurer les fonctionnalités de gestion, dont la sauvegarde et l’archivage de
toutes les informations, au moyen des interfaces appropriées pour les différents
administrateurs ;
• de diffuser les informations aux différents utilisateurs conformément aux règles et
procédures définies, par l’intermédiaire d’un site Internet qui sera développé à
cette fin et par des protocoles d’échange complémentaire, ceci par
l’intermédiaire de requêtes de « post-traitement » ;
• d’effectuer des simulations (étude de scénario) basées sur des jeux de données
différents au moyen de requêtes spécifiques de « scénario » ;
• de permettre la mise à jour des données et des résultats ;
• de faciliter l’évolution future du système (polluants supplémentaires, nouvelles
sources, nouveaux formats de présentation des résultats, etc.).
L’ensemble du projet devra être opérationnel début 2008.
1.2 Objectifs poursuivis

Les applications d’un tel produit sont multiples et s’associent à une meilleure connaissance
de la répartition spatio-temporelle des émissions:
• alimentation en données d’entrée des modèles de qualité de l’air pour la
prévision des épisodes de pollution ou la réalisation de diverses études ;
• complément au dispositif de surveillance de la qualité de l’air ;
• information du public ;
• analyse de tendances concernant l’évolution des émissions en France ;
• mise en perspective de données d’émission avec des données socio-
économiques ou sanitaires : par exemple, en combinaison avec un modèle de
qualité de l’air ou des mesures ambiantes pour des études d’exposition,
d’épidémiologie, etc. ;
• recherche des principaux contributeurs pour un type de polluant, un secteur
géographique donné ;
• rapportage au niveau européen (par exemple, inventaire EMEP) ;
• étude d’impact de nouvelles réglementations relatives aux émissions.
La plate-forme à développer constitue ainsi un élément central, majeur, du système
d’information de l’INS.
5
2 Documents applicables et de référence
2.1 Documents applicables
Document Description Version Auteur Date
Dossier d’architecture logicielle et

[DA1] 1.0 Synapse 27/10/2006
technique
2.2 Documents de référence
Document Description Version Auteur Date
CCTP_ INS_20050629.doc : CCTP

relatif à l’appel d’offre pour la
Ministère de
[DR1] réalisation d’un inventaire national 1.0 29/06/2005
l’Ecologie
spatialisé des émissions de polluants
dans l’air
Ministère
Referentiel_General_Interoperabilite_
[DR2] 0.90 délégué au 07/04/2006
Volet_Technique_V0.90.pdf
budget
Charte_Ergonomique_Application_C
[DR3] MEDD Juin 2004
artographie_Juin04.pdf
Protocoles techniques intermédiaires

(types de données de sortie de la Lots
[DR4] 27/01/2007
plate forme A et volumétrie techniques
associée).
Lots
[DR5] Protocoles techniques définitifs 27/04/2007
techniques
3 Terminologie
3.1 Abréviations
TERME DEFINITION
Inventaire National Spatialisé des émissions de polluants atmosphériques

INS
pour la France
MEDD Ministère de l’Écologie et du Développement Durable
Centre Interprofessionnel Technique d’Etudes de la Pollution
CITEPA
Atmosphérique
INERIS Institut National de l'Environnement Industriel et des Risques
6
3.2 Définitions
TERME DEFINITION
Le rôle de la plate forme A est de compiler l’ensemble des données

Plate-forme A d’inventaire d’émissions de polluants nécessaires au fonctionnement de
la plate-forme B
La plate-forme B assure tous les processus de traitement (spéciation,

granulométrie, temporalisation, spatialisation) à partir des éléments
Plate-forme B
transférés depuis la plate-forme A de façon à répondre aux besoins des
utilisateurs en termes d’expertise et de diffusion.
Une « étude » correspond à l’ensemble des traitements effectués sur les

éléments de la plate-forme B. Elle consiste à sélectionner les fichiers
Une « étude » d’entrée, à sélectionner et/ou à modifier certains paramètres, à
recalculer les émissions et à les restituer selon un format répondant aux
besoins de l’utilisateur.
Le « scénario » est la partie de l’étude consistant à modifier des

paramètres relatifs aux éléments de calcul suivants : niveaux d’émissions,
Un « scénario »
facteurs d’émissions et/ou activité, profils de spéciation, clés de
répartition temporelle.
Le « post-traitement » est la partie de l’étude consistant à spécifier le

format de restitution souhaité en termes de polluants, de spatialisation, de
« post-
spéciation pour certaines substances, granulométrie, composition
traitement »
chimique (sélection d’éléments individuels et/ou agrégats d’éléments),
de distribution temporelle et de regroupement d’activités.
Outil de prévision et de cartographie de la qualité de l’air en France et en

PREV’AIR
Europe
Modèle numérique de simulation du transport et de la chimie des

CHIMERE polluants photo-oxydants et particulaires, utilisé pour le compte du MEDD
dans le cadre d’études d’impact des émissions à l’échelle nationale
Valeur relative des émissions de différents composés à l’intérieur d’une

spéciation famille. Exemple : spéciation des NOx en NO et NO2 à l’émission d’un
véhicules particulier diesel : 10 % NO2 / 90 % NO
4 Objet du marché
Le présent CCTP est relatif à un marché portant sur la conception, la réalisation et la
maintenance évolutive et corrective du système informatique relatif à l’Inventaire National
Spatialisé (INS) des émissions de polluants atmosphériques pour la France.
4.1 Périmètre de la prestation

Les prestations à réaliser par le futur titulaire du lot informatique de l’INS sont décrites dans le
chapitre 5 de ce document. Le projet est découpé en deux phases :
• phase 1 : cette phase s’achève avec la livraison au MEDD des éléments suivants :
o plate-forme B (cf. chapitre 6.1) ;
7
o alimentation du système PREV’AIR (cf. chapitre 6.2) ;

o fonctionnalités du site Internet de l’INS (cf. chapitre 6.3) ;
La phase 1 doit être réalisée dans un délai de 6 mois à compter de la notification du marché.
• phase 2 : elle correspond à la réalisation des éléments permettant la mise en place
d’un outil de gestion et de réalisation de scénarios dérivés de l’INS (cf. chapitre 6.4)
et à la finalisation du site Internet de l’INS. La phase 2 doit être réalisée dans un délai
de 4 mois à compter de l’achèvement de la phase 1.
Deux plates-formes sont décrites dans ce document :
• la plate-forme informatique A accueille l’inventaire national non spatialisé des
émissions de polluants de l’air, base de données résultante de diverses sources
d’informations hétérogènes (sources sectorielles).
• la plate-forme informatique B sera constituée de bases de données de l’inventaire
national spatialisé et des logiciels de traitement et de diffusion associés.
La constitution de la plate-forme A est hors du cadre de ce marché.
Tous les processus présentés dans la suite de ce document sont à réaliser au niveau de la
plate-forme B.
L’attention des soumissionnaires est attirée sur le volume exceptionnel des données traitées et
stockées par cette application. A titre indicatif, le volume de données stocké en archivage
et de données offertes à la publication seront de plusieurs téraoctets.
4.2 Plate-forme A
Le rôle de la plate forme A est de compiler l’ensemble des données d’inventaire d’émissions
nécessaires au fonctionnement de la plate-forme B :
• émissions élémentaires annuelles, consolidation et validation ;
• données associées utilisées par la plate-forme B, comme en particulier des
informations relatives à l’activité (production, consommation etc.), aux clés
temporelles, à la répartition spatiale, etc.
En sortie de la plate-forme A, les émissions et les données d’activité sont disponibles selon les
résolutions sectorielles et spatio-temporelles suivantes :
• résolution sectorielle : activité élémentaire, c'est-à-dire le niveau de calcul le plus fin
disponible dans les protocoles : SNAP/Rubrique/Combustible ou SNAP niveau 3, ou
tout autre niveau relatif à l’activité considérée ;
• résolution spatiale : objet élémentaire, c’est à dire un établissement (généralement
industriel) dans le cas des sources traitées selon une approche ponctuelle, un
tronçon (par exemple de route ou de voie ferrée) constituant une source linéique
ou encore un objet surfacique représentant l’activité considérée (par exemple le
chauffage résidentiel), le plus fréquemment matérialisé par les communes, mais
parfois par les cantons, les zones Corine Land Cover, IRIS-2000 etc. ;
• résolution temporelle : année (sauf dans les cas particuliers des émissions biotiques
et des facteurs d’émissions du transport routier).
Les émissions sont disponibles pour les 38 polluants listés en annexe I directement issus des
protocoles de calcul.
L’hébergement de cette plate-forme sera assuré par le CITEPA.
8
Les protocoles opérationnels, précisant notamment les types de données de sortie de la

plate forme A et la volumétrie associée à ces données, seront fournis au démarrage du
projet. Les protocoles définitifs seront transmis au titulaire du lot le 27 avril 2007.
5 Livrables
Ad-minima, le titulaire s’engage à fournir les livrables décrits dans ce chapitre :
Constitution de la base de données de l’INS

• document de conception détaillé de la base de données (BD) de l’inventaire :
structure de la base de données et description des traitements mis en place pour
générer annuellement cette base de données à partir de la base de données de
la plate-forme A ;
• manuel d’installation de la BD de la plate-forme B ;
• manuel d’exploitation de la BD de la plate-forme B :
o exploitation courante de la BD ;
o archivage d’une année d’inventaire ;
o implantation d’une année d’inventaire archivée.
Alimentation du système PREV’AIR

• document de conception détaillé des traitements mis en uvre pour l’alimentation
du système PREV’AIR.
Site Internet de l’INS

• fichiers sources et images du site Internet de l’INS ;
• manuel d’installation du site Internet ;
• manuel d’exploitation du site internet. Les procédures d’épuration des fichiers
temporaires et des fichiers de données propres aux utilisateurs seront décrites avec
précision ;
• outil(s) de pré-calcul annuel des données de l’inventaire ;
• contenu initial du site Internet de l’INS (transmis par le MEDD) ;
• manuel utilisateur de l’outil de demande et de soumission d’un post-traitement ;
• manuel utilisateur de l’outil d’ordonnancement des requêtes ;
• manuel utilisateur pour la partie sécurisée.
Gestion des scénarios

• document de conception détaillé des fonctions implémentées dans le cadre de la
mise en place des scénarios ;
• manuel utilisateur de l’outil d’administration des utilisateurs ;
• manuel utilisateur de l’outil de demande et de soumission d’un scénario ;
• manuel utilisateur de l’outil d’ordonnancement des scénarios.
Pour le projet dans son ensemble, le titulaire rédigera un Plan Qualité Logiciel ou Plan
d’assurance Qualité (cf. chapitre 10.1).
9
Pour l’ensemble des modules réalisés, le titulaire s’engage à livrer :

• les fichiers sources issus des développements spécifiques relatifs à ce projet ainsi
que les exécutables associés.
• les éventuels outils de reconstructions des exécutables ainsi que la documentation
associée.
• les plans de tests spécifiques à chaque module, les jeux de tests incluant les tests
de non régression ainsi que le résultat des tests effectués avant diffusion pour
recette. Ces tests devront reposer sur des tests nominaux et aux limites. Le titulaire
s’assurera de la complétude des tests élaborés au regard des exigences
attendues.
Il est demandé au titulaire de préciser dans sa réponse le contenu des livrables
documentaires suscités.
6 Description détaillée de la prestation
6.1 Mise en place de la plate-forme B
6.1.1 Présentation
La plate-forme B assure tous les processus de traitement à partir des éléments transférés
depuis la plate-forme A de façon à répondre aux besoins des utilisateurs en termes
d’expertise et de diffusion. La plate-forme B effectue notamment les calculs et traitements sur
les émissions relatives aux polluants sélectionnés dont leur répartition spatiale, temporelle et
sectorielle ainsi que les calculs et traitements nécessaires aux études de scénarios.
En sortie de la plate-forme B les émissions doivent être disponibles selon les résolutions spatio-
temporelles et sectorielles suivantes :
• résolution sectorielle : selon l’utilisateur (secteur d’activité élémentaire, niveaux
SNAP, niveaux SECTEN, définition d’agrégation libre) ;
• résolution spatiale : selon l’utilisateur (grilles prédéfinies ou libres ; unités territoriales –
communes, départements etc.) ;
• résolution temporelle : selon l’utilisateur (heures, jours, mois, saison, année) ;
Les émissions sont disponibles pour les polluants issus des protocoles de calcul et les espèces
spéciées décrites en annexe II.
Il sera également possible de regrouper les espèces spéciées.
Les niveaux de résolution les plus fins accessibles sont dépendants du « niveau d’accès
autorisé » de l’utilisateur. La plate-forme devra être en mesure d’accueillir de nouveaux
polluants et de nouvelles espèces.
L’hébergement de la plate-forme B sera assuré par l’INERIS.
10
6.1.2 Les utilisateurs de la plate-forme B

Trois classes d’utilisateurs de l’INS sont définies :
• « accès libre » : particuliers, bureaux d’étude, associations, industriels, organismes
privés et publics, etc. (a priori, tous les utilisateurs n’entrant pas dans l’une des deux
catégories suivantes) ;
• « mission de service public » : tout organisme de service public intervenant dans le
cadre d’une mission de service public ou répondant à des critères d’éligibilité
définis par le MEDD : AASQA, DRIRE, ministères, laboratoires de recherche publics,
instituts publics, collectivités locales, etc. ;
• « administrateur » : MEDD et les prestataires associés pour la gestion et l’exploitation
de l’INS (CITEPA, INERIS).
En ce qui concerne les utilisateurs en « accès libre », toutes les informations pertinentes seront
disponibles directement sur le site Internet de l’INS. Pour les organismes exerçant des
« missions de service public », toutes les informations disponibles, à l’exception de celles
soumises à des clauses de protection du droit d’auteur ou de confidentialité, seront
accessibles dans le cadre de leur mission après inscription auprès du gestionnaire de l’INS.
L’inscription devra parvenir au gestionnaire de l’INS accompagné d’un engagement à
respecter un certain nombre d’obligations liées à l’utilisation des données.
Les données seront accessibles, en fonction des niveaux d’accès autorisés, selon :
• différents secteurs géographiques : département et commune;
• différentes résolutions temporelles : heure, journée, mois, saison, année ;
• différents secteurs d’activité : les classifications SNAPc et SECTEN ont été adoptées
dans le cadre du projet. La première comprend le classement des émissions en 11
classes principales découpées en plusieurs dizaines de sous-classes. Exemple SNAPc
07 = trafic routier, SNAPc 0701 = trafic routier/voitures particulières, SNAPc 070101 =
trafic routier/voitures particulières/autoroutes. La seconde synthétise les résultats par
grands secteurs d’activités, plus ou moins finement selon le niveau. Ces
classifications SNAPc et SECTEN sont disponibles à l’adresse
« http://www.citepa.org/publications/secten_ fevrier_2006.pdf » respectivement en
annexes 2 et 3.
Les produits disponibles et les modalités d’accès sont différents et définis en rapport avec les
applications types attendues.
11
Une description plus détaillée est donnée dans le tableau suivant :
Utilisateur Applications types Produits
§ Information et § Cartes au km² sur une zone déterminée par

connaissance des l’utilisateur :
émissions
q Ou par département ou commune
§ Etudes d’impact
q Par polluants, sans spéciation
environnemental (état
initial) q Tous secteurs d’activité confondus
§ Répartition de § Histogrammes/camemberts
contributions de
q Répartition des émissions selon le format
sources
SECTEN le plus fin sur une zone et une
§ Etudes d’exposition période données
simples
q Possibilité d’accéder à des données
historiques par polluants (évolution entre
différentes années)
q Par département ou commune
§ Données numériques1 sur une zone
déterminée par l’utilisateur2:
o Résolution km² ou agrégation à une
Accès libre résolution inférieure
o Année/saison
o Secteurs SECTEN ou SNAPc au niveau le plus
fin
o Par polluants pour tous les polluants sans
spéciation
o Années N-1, N-2 et de référence (à terme,
quand 3 années au moins seront
disponibles)
§ Tables de clefs de répartition temporelle
§ Tables de spéciation
1 Présentés sous forme de tableaux .csv (fichiers délimités) par exemple.

2Mêmes possibilités de repérage des zones sur lesquelles il est demandé d’extraire les données
que pour les cartes.
12
Utilisateur Applications types Produits
§ Niveau précédent + § Bases de données d’activité (si non

confidentielles et d’utilisation non
§ PREV’AIR
contraintes par des licences)
§ Etudes pour la
§ Carte sur une zone d’activité déterminée par
surveillance de
l’utilisateur : coordonnées latitude /
qualité de l’air
longitude, Lambert II, Lambert 93.
§ Phénoménologie
§ Bases de données de facteurs d’émission3 (si
§ Etudes d’impact les clauses de confidentialité liées à l’activité
environnemental et ne sont pas opposables)
d’exposition détaillées
Mission de § Données numériques :
(état initial)
service public o Résolution km² ou agrégation à une
§ PPA, PRQA, PDU (état
résolution inférieure
initial)
o Jour/heure
o Secteurs SECTEN ou SNAPc au niveau le plus
fin
o Tous polluants y compris spéciation ou
regroupement, choix laissé à l’utilisateur
o Zone géographique ciblée (liste de
communes, etc.).
§ Niveau précédent § Accès total sans clause de confidentialité

Administrateur § Gestion et réalisation
de scénario
Les modalités d’accès des utilisateurs en accès libre sont en téléchargement sur Internet
(temps réel) de données pré calculées, mises à jour annuellement.
Les accès des utilisateurs de mission de service public sont de trois formes :
• téléchargement sur Internet en temps réel pour les requêtes les plus simples ;
• dépôt des résultats sur le site ftp4 de l’INS pour les requêtes plus complexes
demandant un traitement différé ;
• passerelle particulière vers PREV’AIR : copie de machine à machine sur le site de
l’INERIS.
Pour les utilisateurs de profil « Administrateur (AD) », l’accès à l’information est total sans
clause de confidentialité.
3A résoudre un éventuel problème pour les GSP (Grandes Sources Ponctuelles) qui sont parfois
caractérisées par des facteurs d’émission propres au site. Ainsi dans la formule de base : activité*
facteur d’émission = émission, la connaissance du résultat et du facteur d’émission pourrait
permettre de remonter à des données de production confidentielles. Les soumissionnaires
prendront en compte cet aspect dans leurs soumissions et feront des propositions à cet égard.
4Nécessité d’évaluer la taille de la requête et le temps de mise à disposition. Cette fonctionnalité
permettra également de classer les requêtes «_simples » et « complexes ».
13
Remarques :
• les clefs de répartition temporelle permettant de reconstruire par activité des profils
mensuels, journaliers et horaires seront présentées dans la description de la
méthodologie (par exemple dans un document téléchargeable sur le site de l’INS) ;
• il en sera de même pour les spéciations des particules, des oxydes d’azote, des
composés organiques volatils et de certains métaux (chrome et mercure) ;
• le système sera ouvert de manière à pouvoir ajouter de nouveaux éléments
(polluants, activités, profils de spéciation, profils de distribution temporelle, etc.) ;
• il faut prévoir la possibilité de recalculer chaque jour les émissions susceptibles de
varier en fonction des conditions météorologiques. Cela concerne les émissions
biotiques, les émissions dues notamment à l’évaporation des moteurs et les
émissions du chauffage résidentiel et tertiaire. Cet aspect est fondamental pour
PREV’AIR. Actuellement les émissions biotiques sont calculées chaque jour au
niveau du pré-processeur de PREV’AIR grâce aux données d’occupation du sol et
aux facteurs d’émission. Cette situation sera maintenue dans la période de mise en
place et de test de l’INS sauf si l’option n° X1 est choisie. En tout état de cause, le
titulaire devra prendre en compte le fait qu’à terme la gestion des émissions, y
compris celles dépendant de la météorologie, sera effectuée sur le système INS
(placés en option plus loin) ;
• les utilisateurs hors « accès libre » devront s’enregistrer par courrier auprès du MEDD
et de l’INERIS afin que leur soient affectés un login et mot de passe contre un
engagement à ne pas utiliser les données obtenues dans un cadre autre que celui
de leur mission de service public. Un système automatique de gestion de ces
informations et de renvoi ou réattributions automatiques en cas d’oubli sera prévu.
6.1.3 Les fonctions de la plate-forme B

Trois rôles doivent être assurés par la plate-forme B :
• le traitement des données et le formatage des résultats ;
• la diffusion des résultats par simple consultation ou via des requêtes de post
traitement (cf. paragraphe 6.5) ;
• la gestion et le traitement de scénarios via des requêtes dites de scénario (cf.
paragraphe 6.4).
En fonction des utilisateurs, et en particulier de leur niveau d’accès autorisé, tout ou partie
des fonctions de la plate-forme B est accessible.
Les requêtes de scénario et de post traitement formulées par les utilisateurs sont soumises via
Internet.
L’ « administrateur » de l’INS ne se situant pas sur le site d’accueil de la plate-forme B
disposera d’un émulateur de l’interface utilisateur de la plate-forme B.
Option n°X2a : Les demandes de requêtes de post traitement et de scénario seront formulées
à l’aide d’une grille pré-remplie comprenant les différentes variables modifiables dans le
cadre d’une requête de post traitement (cf. paragraphe 6.5.2) ou de scénario (cf.
paragraphe 6.4.2).
Option n°X2b : les demandes de requête de post traitement et de scénario seront formulées
à l’aide d’une interface utilisateur sur un site Internet permettant à l’utilisateur de saisir seul les
variables (cf. paragraphes 6.4.2 et 6.5.2).
14
6.1.3.1 Traitement et formatage des résultats

Les calculs et traitement peuvent, selon les fonctionnalités et/ou niveaux d’accès autorisés,
être effectués en ligne ou en différé. Le calcul en différé présente l’avantage de pouvoir
exploiter au mieux les ressources machines (calculs de nuit en particulier), en gérant l’ordre
des calculs par exemple en fonction du niveau d’accès autorisé et/ou de l’ordre de
soumission des requêtes.
Au sein d’un même niveau d’accès, des règles automatiques de priorité seront définies sur la
base de l’ordre de soumission des requêtes, du nombre de requêtes soumises et d’un niveau
d’urgence spécifié par l’utilisateur.
L’utilisateur ayant soumis une requête pourra consulter sa position dans la liste de lancement
des requêtes.
Si nécessaire, une intervention du gestionnaire doit permettre de donner la priorité à une
requête plutôt qu’à une autre (ordonnancement manuel des requêtes), ainsi que de lancer
un calcul immédiatement.
Les calculs sont lancés sur la plate-forme B de façon automatique sur la base d’un fichier de
paramètres créé par l’interface de requête. Le format du fichier de paramètres doit donc
être défini de façon à pouvoir répondre à l’ensemble des requêtes possibles sur la plate-
forme B, quel que soit le niveau d’accès autorisé. Ainsi, l’implication du gestionnaire de la
plate-forme B en termes de ressources humaines reste limitée.
Le formatage des résultats consiste à définir les paramètres de post-traitement à appliquer. Il
implique de proposer plusieurs fonctions à l’utilisateur, selon son niveau d’accès autorisé :
• définition des regroupements d’activité ;
• sélection de sources et/ou d’activités ;
• sélection des polluants ;
• sélection de l’année et de la période de l’année ;
• sélection de clés temporelles (via des profils et des peignes définis spécifiques à
chaque activité ou groupes d’activités SNAPc de niveau 3, des banques de
facteurs d’émissions pré calculés ou des calculs horaires spécifiques) ;
• sélection de spéciations (via une nomenclature et des profils définis spécifiques à
chaque activité ou groupes d’activités SNAPc de niveau 3) ;
• regroupement des composés concernés par des spéciations
• sélection du pas de temps d’intégration (heure, jour) ;
• définition de la spatialisation (domaine géographique, origine/taille du repère, pas
de la maille).
Le détail des requêtes relatives à ces fonctions est fourni au chapitre 5.5.
6.1.3.2 Stockage et diffusion des résultats

La diffusion des résultats s’effectue via un site Internet :
• en « accès libre » à partir de données pré calculées parmi lesquelles une sélection
est possible sur la base de la sélection d’un polluant ou d’une activité donnée ;
• en accès différé pour les réponses aux utilisateurs ayant formulé des requêtes de
consultation ou dites de scénario dans le cadre d’une « mission de service public ».
15
6.1.3.2.1 Données diffusées

Les données disponibles à la diffusion dépendent du niveau d’accès autorisé de l’utilisateur.
Le tableau suivant récapitule les caractéristiques des données d’émissions pouvant être
obtenues par niveau d’accès autorisé :
« accès « mission de
Thème « administrateur »
libre » service public »
Grille prédéfinie X X X
Résolution Grille à définir - X X
spatiale des
Commune - X X
émissions,
sélection du
Département X X X
domaine
Région X X X
Génériques X X X
Emissions par
polluants Spéciées /
- X X
agrégés
Uniquement
Total des secteurs X X
PM10, PM2.5
SECTEN au Uniquement
X X
niveau le plus fin PM10, PM2.5
Spéciation SNAPc au niveau
- X X
des émissions le plus fin
Activité
- X X
élémentaire
Regroupement
- X X
libre
Résolution Heure/Jour/Mois - X X
temporelle
des émissions Année / Saison X X X
Date début à
Sélection libre - X X
définir
de la période
Date fin à définir - X X
Total des secteurs X X X
SECTEN au
X X X
niveau le plus fin
Résolution SNAPc au niveau
X X X
sectorielle des le plus fin
émissions
Activité
- X X
élémentaire
Regroupement
- X X
libre
16
sous réserve de
Détails émissions - X
confidentialité
sous réserve de
Activités - X
confidentialité
Données
associées aux Facteurs sous réserve de
- X
émissions d’émission confidentialité
Clés temporelles X X X
Profils de
X X X
spéciation
sous conditions
Scénarios Gestion - d’accès et réserves X
de confidentialité
6.1.3.2.2 Stockage des résultats

Les possibilités de stockage sur la plate-forme B, en termes de taille et de durée, sont
attribuées à l’utilisateur en fonction de son niveau d’accès autorisé.
6.1.3.2.2.1 Nature et taille des données stockées

L’ « accès libre » ne conduit qu’à des résultats prédéfinis et pré calculés. Il s’agit d’un
cadastre d’émissions annuel et saisonnier de polluants par secteur d’activité SECTEN et SNAP
au niveau le plus fin. Ces valeurs étant pré calculées, l’affichage à travers l’interface SIG et le
téléchargement des images affichées et des données associées sont quasi immédiats.
Les utilisateurs de « mission de service public » ont la possibilité de soumettre des requêtes de
consultation ou des requêtes dites de scénario qui sont calculées « en différé ». Afin de
permettre l’exploitation des résultats et en particulier leur analyse, les résultats sont
accompagnés d’une partie des données ayant servi à les générer, et en particulier :
• le fichier de paramètres de l’étude ;
• les fichiers d’entrée des calculs (spéciations, clés temporelles etc.).
Les résultats et les données associées sont compressés selon le format de compression retenu
(.rar ou .zip). Le répertoire résultant est déposé sur le site ftp spécifié par l’utilisateur, qui est
averti par courriel de l’issue de la requête et de la mise à disposition des résultats.
L’ « administrateur » de l’INS soumet des requêtes de consultation ou dite de scénario qui sont
calculées « en différé ». Lors de la création d’une nouvelle étude (scénario ou/et post-
traitement), un répertoire est créé dans lequel l’ensemble des fichiers d’entrée sont dupliqués
et dans lequel le fichier de paramètres et les résultats sont stockés. L’ensemble des données
nécessaires et suffisantes à régénérer l’étude doit être dans ce répertoire. Une fonction de
compression/décompression (.rar ou .zip) est à disposition de l’utilisateur.
On peut envisager que certaines des requêtes les plus courantes des utilisateurs soient pré
calculées. Il ne pourra s’agir que de requêtes présentant un compromis satisfaisant entre
temps de calcul et volume de données à stocker.
6.1.3.2.2.2 Durée de stockage temporaire

Dans le cas des utilisateurs de « mission de service public » qui ne disposeraient pas de site
ftp, les résultats sont stockés de façon temporaire sur le serveur ftp de la plate-forme B. Ce
stockage n’excède pas une période donnée paramétrable par l’administrateur et dont
17
l’utilisateur aura connaissance par l’envoi du courriel d’information de la mise à disposition

des résultats.
L’ « administrateur » de l’INS a la possibilité de soumettre des requêtes de consultation ou
dites de scénario qui sont calculées « en différé ». Les études (scénario, post-traitement) sont
alors stockées sur un espace disque limité qui leur est consacré.
Le lancement de la requête doit être conditionné à une estimation de l’espace disque
nécessaire pour stocker le répertoire de sortie. Cette estimation est indiquée à l’utilisateur qui
s’assure alors qu’il peut transférer et stocker un tel volume. Si l’espace disque disponible n’est
pas suffisant sur la plate-forme B, l’utilisateur est informé que sa requête sera différée jusqu’à
libération d’un espace disque suffisant.
6.1.3.2.3 Affichage des résultats

Les données à diffuser pourront être visualisées sous forme cartographique par l’utilisateur au
moyen d’Internet.
A priori, l’affichage des résultats à travers l’interface prédéfinie sera plus particulièrement
utilisé par le grand public via l’ « accès libre ». Il ne nécessite donc pas de proposer de
fonctionnalités complexes de type « requête ».
Les utilisateurs de « mission de service public » disposent de moyens d’exploitation qui leur
permettent a priori d’analyser et d’exploiter plus finement les résultats de la plate-forme B
(exportées sous forme de données numériques). A l’exception des sorties prévues pour le
public en « accès libre », aucune interface d’affichage des résultats de requêtes ne sera
spécifiquement proposée aux utilisateurs de « mission de service public ».
L’ « administrateur » de l’INS dispose du SIG de la plate-forme B pour traiter les résultats.
Cependant, par souci de commodité, une interface utilisateur complète, dédiée
spécifiquement à l’analyse des sorties de l’INS, est demandée. Cette fonctionnalité est
possible dans la mesure où les résultats des requêtes restent stockés sur la plate-forme B.
L’interface en « accès libre » pour le grand public correspond alors à une version « bridée »
de l’interface complète.
6.1.3.2.3.1 Affichage des valeurs de sortie de la plate-forme B

Les données diffusées sont fonction du niveau d’accès autorisé. L’affichage de ces données
sera conforme aux définitions de diffusion (Cf. tableau relatif aux données diffusées).
6.1.3.2.3.2 Affichage de couches cartographiques complémentaires

Pour faciliter l’analyse des résultats, l’utilisateur pourra choisir d’afficher une ou plusieurs
couche(s) cartographiques en plus de la couche contenant les résultats à visualiser.
Ces couches cartographiques seront sélectionnées par l’utilisateur dans une liste comportant
au minimum les couches suivantes, issues de la BD Carto de l’IGN dont le MEDD a acquis les
droits :
• limites administratives de la France (régions, départements, affichées par défaut),
communes ;
• réseau hydrographique principal ;
• villes principales ;
• réseau routier principal du lot 3 .
Cette liste n’est pas exhaustive et devra pouvoir être complétée en fonction de ses besoins.
Ainsi, il est possible de permettre à l’utilisateur d’importer et d’afficher n’importe quelle
18
couche cartographique selon un format compatible avec le SIG de la plate-forme B, par le

biais de services OGC.
La liste des couches cartographiques de base proposées devra pouvoir être complétée.
6.1.3.2.3.3 Fonctions de navigation

Plusieurs fonctions de navigation seront disponibles à travers l’interface utilisateur. Ces
fonctions seront définies dans le document [DR3]. Plusieurs fonctions standard seront
disponibles pour faciliter la consultation des résultats :
• choix des couches cartographiques ;
• zoom avant et arrière ;
• déplacement de la fenêtre d’affichage (droite, gauche, haut, bas) ;
• coordonnées du curseur selon la projection d’affichage ;
• échelle de la carte ;
• légende.
Option n°X : une fonction de zoom avec seuil d’affichage, l’affichage de méta données
(nom des objets, valeurs), etc. sera incluse.
6.1.3.2.4 Diffusion des résultats

Deux modes de diffusion sont envisagés sur la plate-forme B :
• Internet ;
• FTP (File Transfert Protocol).
6.1.3.2.4.1 Internet
Internet constitue le moyen d’interrogation (requêtes en ligne) et de diffusion de certains des
résultats. Le mode de diffusion via Internet sera dédié à la consultation en ligne de résultats
pré-calculés et au téléchargement d’images (cartes) et de documents de petite taille. Il est
plus particulièrement destiné au public en « accès libre ».
Un site devra donc être développé de sorte à assurer ces fonctionnalités. Les fonctionnalités
principales de ce site sont décrites au chapitre 5.3.
6.1.3.2.4.2 Ftp
Le mode de diffusion par dépôt sur un site ftp est dédié aux requêtes différées.
Ce mode de diffusion est particulièrement adapté au transfert de volumes importants de
données qui seront déposées sur le site ftp de l’INS.
6.2 Alimentation du système PREV’AIR
6.2.1 Le système PREV’AIR et le modèle CHIMERE

Le système PREV’AIR (http://www.prevair.org/fr) est un outil de prévision et de cartographie
de la qualité de l’air en France et en Europe, fruit d’une collaboration étroite entre l’Agence
De l’Environnement et de la Maîtrise de l’Energie (ADEME), l’Institut Pierre-Simon Laplace du
CNRS (IPSL), Météo France et l’INERIS.
Entre autres produits de sortie, PREV’AIR fournit des cartes de prévisions des concentrations
moyennes et maximales d’ozone, de dioxyde d’azote et de particules pour les deux jours à
19
venir sur l’Europe de l’ouest et sur la France. Ces prévisions sont établies à l’aide de modèles
numériques fonctionnant sur la base de données d’émission de référence, d’une description
fine de l’occupation du sol, et de prévisions météorologiques; c’est ainsi que le modèle
CHIMERE (IPSL/CNRS-INERIS), dédié à la simulation du transport et de la chimie des polluants
photo-oxydants et des particules, est mis en uvre quotidiennement à l’INERIS.
En parallèle des travaux réalisés dans le cadre de PREV’AIR, l’INERIS utilise le modèle CHIMERE
pour apporter un appui technique au MEDD pour toutes les questions relatives au transport à
longue distance de la pollution atmosphérique. L’INERIS travaille également sur les
problématiques d’évaluation des modèles de qualité de l’air, d’analyse des incertitudes, et
d’efficacité de scénarios alternatifs de réduction des émissions.
Dans le cadre du projet d’Inventaire National Spatialisé (INS), le titulaire doit prendre en
charge :
• l’alimentation du système PREV’AIR en données d’émissions.
• l’outil de création de scénarios rattaché à l’INS doit permettre d’alimenter le
modèle CHIMERE en données d’émissions issues de scénarios.
Les fonctionnalités attendues de l’INS et de l’outil de création de scénarios concernant le
système PREV’AIR et le modèle CHIMERE sont décrites ci-après.
6.2.2 Emissions anthropiques

Les données d’émissions anthropiques utilisées sur la France par le système PREV’AIR / le
modèle CHIMERE se présentent sous la forme de fichiers « texte » EMISSIONS_FRA10.i, i=01, 02,
…, 12 ; chaque fichier est relatif à un mois de l’année.
Le format des données est le suivant :
• Ne=1, nemisa ;
• Nt=1, ntypeday ;
• Nh=1, nhoriz ;
• (Emission(ih,nl),ih=1,nhourpday),nl=1,nlevemis).
avec nemisa = nombre d’espèces modèles anthropiques émises; ntypeday = 3 ; nhoriz =
nombre de points de grille du domaine considéré; nhourpday = 24 ; nlevemis = nombre de
niveaux verticaux dans lesquels se répartissent les émissions.
Le format des fichiers d’émissions attendus pour l’alimentation du système PREV’AIR seront
transmis au titulaire.
A l’heure actuelle, les émissions sont construites à partir des totaux annuels d’émissions EMEP,
spatialisés sur la grille EMEP, disponibles pour de grandes familles de polluants (NO x, SOx,
COVNM, CH4, PM), par secteurs SNAP.
Les traitements sont découpés ainsi :
1. Etape de spatialisation : redistribution des totaux annuels d’émissions sur la grille
PREV’AIR ;
2. Etape de spéciation : pour chaque secteur SNAP, les émissions totales de COVNM
sont réparties sur un ensemble de COVNM réels ;
3. Etape de temporalisation : des profils temporels sont appliqués ;
4. Etape d’agrégation : les émissions de chaque COVNM réel sont affectées à un ou
plusieurs COVNM modèles.
20
Les données nécessaires à la réalisation des trois premières étapes seront disponibles via la
plate-forme B quelle que soit l’application visée. La quatrième étape est propre au modèle
mis en uvre dans le cadre de PREV’AIR. Mais l’ensemble permet de définir les quatre
premières fonctionnalités que l’INS doit comporter pour répondre aux objectifs associés à
PREV’AIR :
• F1 : agrégation des données d’émission sur une grille ayant une résolution
généralement moins fine que le km², typiquement 10km*10km pour la configuration
actuelle de PREV’AIR sur la France ;
• F2 : application des profils de spéciation ;
• F3 : application des clefs de répartition temporelle ;
• F4 : agrégation des émissions relatives aux espèces chimiques réelles en émissions
formatées pour les modèles. La plate-forme B possède une telle fonctionnalité qui
consiste :
o à donner la possibilité à l’utilisateur de définir les regroupements qui lui semblent
pertinents ;
o à calculer les émissions spéciées correspondantes et à les formater selon les
exigences de PREV’AIR.
6.2.3 Emissions biotiques

Les données d’émissions biotiques utilisées sur la France par le système PREV’AIR sont
construites chaque jour à partir de données d’entrée relatives à l’occupation du sol, aux
facteurs d’émissions disponibles pour un certain nombre d’essences et à partir des conditions
météorologiques prévues :
1. les émissions nominales - associées à des conditions standard de température et
d’ensoleillement - sont calculées ;
2. elles sont modulées chaque jour pour la période de prévision en fonction de la
température et de l’ensoleillement effectivement prévus.
Les données nécessaires à la réalisation de la première étape seront disponibles via la plate-
forme B. La deuxième étape est propre à chaque période de prévision et est mise en uvre
actuellement dans le cadre de PREV’AIR. A terme, il est souhaitable que, de façon similaire à
certaines émissions anthropiques, ces calculs « au jour le jour » soient effectués directement
sur la plate-forme de l’INS.
6.2.4 Dépendance des émissions anthropiques et biotiques vis à vis des conditions
météorologiques
L’outil de gestion de l’INS doit permettre le calcul des émissions anthropiques et biogéniques
pour l’année de référence (pour des conditions météorologiques climatologiques
mensuelles).
Actuellement, la dépendance aux conditions météorologiques de certaines émissions
anthropiques n’est pas prise en compte dans PREV’AIR, mais cela constitue une voie
d’amélioration de la prévision. Plusieurs fonctionnalités de calcul au jour le jour d’une
certaine catégorie d’émission en fonction des prévisions météorologiques sont requises :
• F5 : acquisition de données de prévisions de données météorologiques avec une
certaine résolution spatiale et une résolution temporelle horaire, auprès du système
PREV’AIR pour alimenter le calcul sur la plate-forme B ;
• F6 : calcul des émissions dépendant de ces données : a minima émissions biotiques.
21
Option n°X1 : des fonctionnalités spécifiques seront intégrées à la plate-forme B afin de faire
dépendre des conditions météorologiques, les émissions dues au trafic (à chaud,
évaporation), aux sources biotiques et au chauffage résidentiel et tertiaire. Ces trois types de
données d’émission devront en conséquence être recalculés sur la plate-forme B en fonction
de deux paramètres météorologiques d’entrée : température et ensoleillement :
• F7 : restitution des résultats au système PREV’AIR ;
Enfin, en vue de l’analyse d’épisodes météorologiques particuliers (type canicule), l’outil de
gestion de l’INS devra également permettre le calcul des émissions anthropiques et biotiques
pour des périodes particulières.
6.3 Mise en uvre du site Internet de l’INS

Le site Internet de l’INS aura pour fonctions :
• la diffusion de résultats pré calculés mais aussi de résultats de requêtes de post-
traitements ;
• la soumission de requêtes différées de post traitement en fonction de l’option X2a
ou X2b ;
• la soumission de requêtes différées de scénario en fonction de l’option X2a ou X2b ;
• l’accès à un espace protégé (ftp) pour la fourniture des résultats de requêtes
différées.
6.3.1 Navigation et Graphisme
6.3.1.1 Contraintes de navigation

Une attention particulière sera observée lors de la conception ergonomique et cinématique
du site Internet de l’INS.
Le titulaire devra privilégier une solution permettant une navigation claire et rapide.
L’intégration du module de visualisation devra être le plus transparent possible pour
l’utilisateur et bénéficier d’une ergonomie identique au reste du site.
Les menus constituant le fil directeur de la navigation devront être affichés en permanence,
sur toutes les pages et constitueront le « sommaire » du site.
Les liens externes, les liens vers des fichiers ou des images renverront l’internaute dans une
nouvelle fenêtre.
Les temps de téléchargement d’images et animations seront réduits au strict minimum.
6.3.1.2 Charte graphique

Le logo du MEDD, accompagné de l’identifiant gouvernemental (Marianne) doit
obligatoirement figurer dans le graphisme et être visible à tout moment de la navigation.
La charte graphique sera précisée au démarrage du projet au seul titulaire retenu. Le
graphisme devra être clair, aéré, dynamique et vivant, et basé sur celui du site ministériel
(www.ecologie.gouv.fr).
6.3.1.3 Réalisation de gabarits

Les contraintes suivantes devront être prises en compte dans la définition du graphisme et
de l’ergonomie :
• les pages doivent être imprimables ;
22
• les polices de caractères doivent être lisibles et avoir un visuel agréable ;

• les libellés utilisés doivent être compréhensibles.
Le titulaire devra proposer a minima deux maquettes et leurs déclinaisons pour les différents
gabarits.
6.3.1.4 Contraintes de configuration

Le choix du graphisme devra tenir compte des exigences suivantes :
• visualisation optimale pour des écrans 1024 - 256 couleurs minimum et adaptée
pour des écrans 800 x 600 ;
• systèmes d’exploitation Windows 95/98, 2000 Pro et Server, Xp Pro, Macintosh OS X ;
• navigateurs IE 5.0 et versions supérieures, Firefox, Netscape 4.5 et supérieures.
6.3.1.5 Option n°X3 : autres fonctionnalités

Le titulaire reste libre de proposer des fonctionnalités supplémentaires à la solution de base
prévue dans ce document.
6.3.2 Gestion de contenu

Le site de l’INS devra se structurer ainsi :
1. La page d’accueil, point d’accès central vers les différentes rubriques du site.
2. Le contenu rédactionnel : une documentation descriptive de l’INS sera mise à
disposition de tous les utilisateurs de ce site. Ce contenu détaillera notamment les
méthodologies employées dans le cadre de ce projet, les catégories SECTEN, …
Cette documentation ainsi que les liens externes éventuels vers d’autres sites seront
fournis au titulaire. Une mise à jour annuelle est prévue pour ce type de contenu.
6.3.3 Visualisation des cartes.

Les données disponibles en accès temps réel ainsi que les traitements disponibles en accès
différé, seront conformes aux attentes formulées au chapitre 5.1.3 (Fonctions de la plate-
forme B).
6.3.4 Gestion des scénarios

Les fonctions précises à prendre en compte sont détaillées au chapitre 5.4 (Gestion des
scénarios).
6.3.5 Gestion des requêtes de post traitement.

Les fonctions précises à prendre en compte sont détaillées au chapitre 5.5 (Gestion des
requêtes).
6.3.6 Génération des données pré calculées

Un traitement spécifique devra être mis en place pour générer chaque année les données
pré-calculées de l’INS, affichées soit sous forme de cartes, soit téléchargeables sous la forme
de fichiers de données.
6.3.7 Autres exigences

Le site sera conçu de façon à permettre un référencement initial sur la page d’accueil afin
qu’il soit référencé par des moteurs de recherche de type Yahoo et Google.
23
6.4 Gestion de scénarios

Une fonctionnalité de la plate-forme B est son exploitation dans le cadre de divers travaux
scientifiques et techniques relatifs aux scénarios, par exemple :
• projets d’aide à la décision (études d’impact, études de cas, etc.) ;
• projets de recherche théoriques ;
• travaux de validation de la plate-forme (comparaison à des inventaires locaux
existants), etc.
Cette exploitation « avancée » de la plate-forme B implique d’offrir à l’utilisateur plusieurs
fonctions, à savoir :
• l’ajustement des émissions, des facteurs d’émission, des paramètres d’activité, des
conditions météorologiques pour les sources biotiques, etc. ;
• le lancement des calculs de scénarios ;
• la gestion des résultats.
Option n°X1 : si l’option n°X1 est choisie, des fonctionnalités spécifiques seront intégrées à la
plate forme B – gestion de scénario afin que les émissions dues au trafic (à chaud,
évaporation), aux sources biotiques et au chauffage résidentiel et tertiaire dépendent des
conditions météorologiques. Ces deux types de données d’émission devront en
conséquence être recalculés sur la plate-forme B en fonction de deux paramètres
météorologiques d’entrée : température et ensoleillement.
Relativement à ces fonctions, des requêtes spécifiques, dites de scénario, sont détaillées au
paragraphe 6.5.1.
6.4.1 Accès aux fonctions

L’accès aux fonctionnalités des scénarios est limité à l’ « administrateur » de l’INS et aux
utilisateurs de « mission de service public ». Il s’agit de fonctions de lecture (affichage des
données) et de fonctions de modification (actions sur certains paramètres de calcul).
Les fonctions de lecture permettent l’affichage de données associées au scénario dans le
cas de la consultation d’un scénario existant y compris les jeux de données des années
référencées
Les fonctions de modification permettent de modifier certains paramètres de calcul pour
construire les scénarios selon les choix opérés par l’utilisateur : modifications en valeurs
absolues, ou en relatif avec regroupement sectoriel et/ou spatial.
6.4.2 Soumission des scénarios

La définition de scénarios est réalisée au moyen de requêtes soumises à la plate-forme B à
travers une interface dédiée. Sur ce thème, les soumissionnaires se référeront au paragraphe
6.1.3.
Le module de calcul « scénarios » permettra de modifier les bases de données d’activités et
de facteurs d’émission, les clefs de répartition, ainsi que les conditions météorologiques
(valeurs de température, etc.). Ces modifications peuvent être exprimées en valeur absolue
(remplacement d’une valeur par une autre) ou en valeur relative (pourcentage de
variation).
Une table de définition sera établie pour décrire les scénarios. Le gestionnaire de la plate-
forme B se chargera alors de saisir ces scénarios via l’interface homme-machine dédiée à ce
24
service et développée de manière connexe à l’INS par le titulaire du lot « informatique ». La

mise en uvre du calcul sera réalisée sur cette plate-forme.
A terme, l’interface homme machine permettra la saisie des paramètres des scénarios et le
lancement des calculs sans nécessiter l’intervention de l’ « administrateur » (notamment
lorsque la puissance de calcul permettra de s’affranchir des contraintes de temps de calcul
et de gestion des requêtes). Cette évolution doit être prise en compte dès à présent.
Option n°X : réalisation d’une interface homme machine permettant la saisie des paramètres
des scénarios et le lancement des calculs ne nécessitant pas l’intervention de
l’administrateur.
6.4.3 Outil de création des scénarios

• F1 : pour chaque type de source, modification des paramètres d’activité :
production industrielle, nombre de véhicules, répartition du parc des véhicules … Il
doit être possible d’en établir une liste à partir des protocoles de chacun des lots. A
noter que seuls les paramètres entrant directement dans le calcul des émissions
doivent pouvoir être modifiés. Ainsi, on ne s’attachera pas à prendre en compte
l’évolution du nombre d’employés d’une entreprise ou sa consommation
d’électricité. Les paramètres d’activité doivent pouvoir être modifiés en valeur
absolue ou en valeur relative (%) ;
• F2 : pour chaque type de source, modification des facteurs d’émission, y compris
ceux relatifs à la granulométrie des particules le cas échéant. Les facteurs
d’émission doivent pouvoir être modifiés en valeur absolue ou en valeur relative
(%) ;
• F3 : possibilité de modifier directement les valeurs d’émission (i.e. le produit activité
par facteur d’émission), en absolu ou en relatif ;
• F4 : possibilité d’effectuer des modifications seulement sur certaines zones
géographiques. Il faut donc avoir le choix des agglomérations, des quartiers, des
portions du réseau routier ou des aires géographiques sur lesquels l’on souhaite
appliquer le calcul de scénario. Ce repérage se fera idéalement par un SIG par
saisie d’un polygone de travail ;
• F5 : possibilité d’effectuer des modifications sur une période seulement ;
• F6 : possibilité de déplacer, supprimer certaines sources ou d’en ajouter, à l’aide
du SIG ;
• F7 : modification des données météorologiques sur certaines périodes. Le module
de calcul doit donc prévoir de récupérer de nouvelles données fixées par
l’utilisateur dans un format prédéfini, de traiter les émissions dépendant de ces
informations, et de les restituer ;
• F8 : modification des profils de spéciation ;
• F9 : modification des clefs de répartition temporelle ;
• F10 : visualisation du résultat des calculs de scénarios. Une synthèse, sous forme
d’éléments chiffrés et cartographiés relatifs aux émissions par secteur, par
polluant…, devra être disponible pour l’utilisateur à l’issue de calcul de scénario ;
• F11 : Module de prévision de la durée de calcul et du volume de stockage d’un
scénario.
25
6.5 Requêtes
Deux types de requêtes doivent être disponibles sur la plate-forme B :
• des requêtes prédéfinies, qui permettent à l’utilisateur de répondre à des besoins
fréquents spécifiés a priori lors de la phase de conception de la plate-
forme (nomenclatures, grille de calcul) ;
• des requêtes paramétrables, qui laissent à l’utilisateur « expert » le choix d’un certain
nombre de paramètres de la requête (grille de calcul, pas de temps d’intégration,
sélection de sources).
Les requêtes paramétrables et les enchaînements de requêtes doivent pouvoir être
enregistrés dans la liste des requêtes possibles.
Pour répondre à l’ensemble des fonctions requises, deux catégories de requêtes doivent être
disponibles sur la plate-forme B :
• des requêtes relatives aux « scénarios » permettant l’ajustement :
o des émissions ;
o des facteurs d’émission ;
o du paramètre d’activité ;
o du profil de spéciation ;
o du pas de temps ;
• des requêtes relatives au « post-traitement » permettant de préciser le format
d’obtention des données en fonction :
o de la spatialisation ;
o du regroupement d’activités : requête sectorielle ;
o des spéciations : requête de regroupement ;
o du pas de temps : requête temporelle.
Ces deux catégories de requêtes doivent pouvoir être combinées.
26
6.5.1 Requêtes de « scénario »
6.5.1.1 Requête d’ajustement des émissions

La requête d’ajustement des émissions a pour objet de spécifier de nouvelles valeurs ou
d’appliquer des coefficients d’évolution aux émissions « de base » c'est-à-dire calculées selon
les protocoles techniques.
Ces coefficients d’évolution peuvent avoir une dimension spatiale, à l’échelle de la
commune, du département ou de la région.
Ces coefficients doivent en outre pouvoir être attribués par niveau d’activité le plus fin, c’est
à dire par source (ID). Cependant des facilités d’attribution par « regroupement » d’activités
doivent être prévues à tous les niveaux (SNAP/Rubrique/Combustible ; SNAP niveau 3 ; SNAP
niveau 2 ; SNAP niveau 1 ; Type de sources).
6.5.1.2 Requête d’ajustement des facteurs d’émission (FE)

La requête d’ajustement des facteurs d’émission a pour objet :
• soit d’appliquer des coefficients d’évolution aux facteurs d’émissions de l’inventaire
de référence ;
• soit de spécifier la valeur du facteur d’émission à considérer.
Ces valeurs (relatives ou absolues), doivent pouvoir être attribuées par polluant et par niveau
d’activité le plus fin, c’est à dire par source (ID). Cependant des facilités d’attribution par
« regroupement » d’activités doivent être prévues à tous les niveaux (SNAP/Rubrique/
Combustible ; SNAP niveau 3 ; SNAP niveau 2 ; SNAP niveau 1 ; Type de sources).
6.5.1.3 Requête d’ajustement du paramètre d’activité

La requête d’ajustement du paramètre d’activité a pour objet :
• soit d’appliquer des coefficients d’évolution aux paramètres d’activité de
l’inventaire de référence ;
• soit de spécifier la valeur du paramètre d’activité à considérer ;
• soit de rajouter une source.
Ces valeurs (relatives ou absolues), doivent pouvoir être attribuées par niveau d’activité le
plus fin, c’est à dire par source (ID). Cependant des facilités d’attribution par
« regroupement » d’activités doivent être prévues à tous les niveaux
(SNAP/Rubrique/Combustible ; SNAP niveau 3 ; SNAP niveau 2 ; SNAP niveau 1 ; Type de
sources).
6.5.1.4 Requête scénario de « spéciation »

Des profils de spéciations par défaut sont proposés pour chaque activité élémentaire (selon
le cas combinaison en tout ou partie de SNAP niveau 3, NAPFUE, rubrique). Sauf
spécifications contraires, ces profils de spéciation, décrits dans les tables de profils de
spéciation, sont appliqués.
L’utilisateur peut cependant vouloir appliquer de nouveaux profils de spéciation.
La requête de spéciation consiste à appliquer des profils de spéciation différents de ceux
spécifiés par défaut.
27
6.5.1.5 Requête scénario de « clés temporelles »

Les éléments de la plate-forme B sont établis sur une base annuelle. La plate-forme B doit
donc disposer des éléments permettant de déterminer les émissions au pas de temps horaire.
Cette opération s’effectue, sauf cas particulier, sur la base de clés de répartition temporelle.
Des clés de répartition par défaut sont donc proposées pour chacun des secteurs d’activité
élémentaires.
Dans le cadre d’un scénario, l’utilisateur peut vouloir appliquer soit de nouvelles clés (par
secteur d’activité ou par source), soit, des chroniques de mesures dans le cas des GSP les
mieux documentées.
La requête de clés « temporelles » consiste à appliquer des clés temporelles différentes de
celles spécifiées par défaut, ou à exploiter des chroniques de mesures spécifiques pour
certains polluants.
Ces clés doivent pouvoir être appliquées par secteur d’activité élémentaire
SNAP/Rubrique/Combustible (ID_sect) ou par source (ID).
6.5.2 Requêtes de « post-traitement »
6.5.2.1 Requêtes de spatialisation

La requête de spatialisation permet à l’utilisateur de la plate-forme B de définir le type de
résolution géographique souhaitée, c'est-à-dire de définir la grille ou l’entité territoriale
d’attribution des émissions de l’objet élémentaire. Les calculs d’émissions par objet de
restitution sont alors réalisés par un module dédié sur la base de la localisation des sources et
des BD géographiques.
L’utilisateur doit pouvoir sélectionner une grille prédéfinie ou en définir une nouvelle. Dans le
cas de la spécification d’une nouvelle grille, les paramètres de la grille doivent pouvoir être
définis en termes de projection, d’origine et de pas.
L’utilisateur doit pouvoir choisir de sélectionner une couche d’entités territoriales de restitution
parmi celles proposées par défaut (commune, départements, régions) ou en spécifier une
nouvelle.
La projection des émissions des entités administratives sur une grille spatiale doit pouvoir se
faire au moyen d’un indicateur intermédiaire de spatialisation (catégories d’occupation du
sol Corine Land Cover, densité de population etc.). Un indicateur de répartition par défaut
est proposé dans le cadre de l’inventaire de référence par type d’activité.
Toutefois, dans le cadre d’un post-traitement, l’utilisateur (hors accès libre) peut souhaiter
spécifier un nouvel indicateur intermédiaire de répartition. A cette fin plusieurs paramètres
doivent pouvoir être définis à travers l’interface :
• la couche cartographique (sélectionnée dans la bibliothèque disponible) ;
• le champ associé ;
• un (ou plusieurs) identifiant(s) des indicateurs de répartition ;
• la part attribuée à chaque identifiant.
Les calculs d’intersection entre les objets de restitution et les sources (qu’elles soient traitées
selon une approche ponctuelle, linéaire ou surfacique), doivent être réalisés par l’outil SIG de
la plate-forme.
Ainsi, par exemple, les émissions de l’inventaire de référence liées au chauffage résidentiel
pourraient être réparties sur une nouvelle grille en utilisant comme indicateur de répartition le
28
type d’occupation du sol décrit dans la couche cartographique Corine Land Cover, et en
particulier les identifiants « urbain dense » et « urbain dégagé ».
6.5.2.2 Requête sectorielle

La requête sectorielle permet à l’utilisateur de la plate-forme B de définir l’agrégation
sectorielle souhaitée, c'est-à-dire de définir les regroupements d’activités en fonction de
l’activité élémentaire SNAP/Rubrique/combustible ou du code SNAP. Il est ainsi possible de
fournir les résultats selon le format de restitution, dit de « reporting », défini par l’utilisateur
(dans la limite du référentiel originel).
6.5.2.2.1 Requêtes prédéfinies

Des requêtes prédéfinies doivent permettre des regroupements sectoriels selon les formats de
restitution les plus classiques, à savoir :
• tous secteurs ;
• SECTEN niveau 1 ;
• SECTEN niveau 2 ;
• SNAP niveau 1 ;
• SNAP niveau 2 ;
• SNAP niveau 3.
6.5.2.2.2 Requêtes paramétrables

La définition de requêtes paramétrables doit permettre à l’utilisateur de spécifier une
variante de format de restitution adaptée à ses besoins, c'est-à-dire de constituer et de
nommer des groupes d’activités élémentaires.
6.5.2.3 Requête de regroupement

Des profils de spéciations par défaut sont proposés dans les tables de profils de spéciation
pour chaque activité élémentaire (selon le cas combinaison en tout ou partie de SNAP
niveau 3, NAPFUE, rubrique). Ils sont utilisés dans les calculs induits ou non par les requêtes
selon la catégorie d’utilisateur.
6.5.2.4 Requête temporelle

Les éléments de la plate-forme B sont établis en général sur une base annuelle. La plate-
forme B doit donc disposer des éléments permettant de déterminer les émissions au pas de
temps horaire. Cette opération s’effectue, sauf cas particulier, sur la base de clefs
d’allocation temporelle. Des clefs par défaut sont proposées pour chaque activité SNAP de
niveau 3 ou regroupement d’activités.
Les cas particuliers concernent les sources biotiques et le trafic routier pour lesquels le calcul
des émissions intègre directement la dimension temporelle.
Les données peuvent être fournies en sortie aux résolutions temporelles suivantes :
• heure ;
• jour (discrimination possible entre jour de semaine, samedi, dimanche et jour férié) ;
• mois ;
• saison ;
• année.
29
7 Organisation et gestion de projet
7.1 Description de l’équipe projet

Le titulaire transmettra la composition de l’équipe pressentie sous forme de profils et en
décrira l’organisation.
Le titulaire notifiera au maître d’ouvrage, les remplacements des intervenants proposés lors
de la consultation. Dans ce cas, tout nouvel intervenant présentera alors des compétences
équivalentes à celui remplacé.
La proposition fera également apparaître la répartition des tâches en fonction des profils
proposés :
• un responsable de projet senior avec :
o de réelles qualités relationnelles et rédactionnelles ;
o une facilité d’appréhension du fonctionnel ;
• un ou plusieurs architectes techniques avec :
o une expérience des systèmes d’information dans leur globalité ;
o une expérience sérieuse dans la mise en place de solutions SIG de cette
envergure ;
o une expérience des bases de données, et la conception de celles-ci d’un point
de vue architectural ;
o une facilité de vulgarisation des concepts et technologies rencontrés ;
• un ou plusieurs ingénieurs d’études avec :
o une expérience dans la mise en place de solutions SIG ;
o une expérience des bases de données.
7.2 Planning
Le titulaire devra proposer une organisation et un planning permettant la validation
successive des réalisations effectuées. Un planning prévisionnel de chaque phase est donc à
fournir par le titulaire.
En plus d’une liste des tâches avec, pour chacune, mention de la charge de travail
nécessaire à sa réalisation, ce planning présentera l’ordonnancement des tâches. Il fera
apparaître les tâches séquentielles et les tâches en parallèle, les points de convergence et le
chemin critique, par étape.
Le planning sera actualisé régulièrement en fonction de l’avancement avec le comité de
suivi. Le niveau de détail permettra d’identifier chacune des tâches affectées à chaque
exécutant. Le planning mettra en évidence les tâches et actions assurance ou contrôle
qualité.
Le document support du planning détaillé devra au moins récapituler, pour chaque tâche :
• le temps prévu initialement ;
• le temps passé sur la période ;
• le temps passé cumulé ;
30
• le reste à consommer ;
• le reste à faire (charge nécessaire à la terminaison de la tâche) ;
• l’écart prévisionnel (reste à consommer - reste à faire).
7.3 Réunions d’avancement

Pour toute la durée du marché, les réunions d’avancement auront lieu en fonction des
besoins à Paris dans les locaux du MEDD ou du CITEPA, ou à Verneuil dans les locaux de
l’INERIS :
• une réunion de lancement en début de prestation : elle aura pour objet de
balayer avec le titulaire l’existant et de reformuler les besoins en présence de
l’ensemble du comité de suivi ;
• au minimum une réunion de suivi d’avancement par mois.
En dehors des réunions d’avancement, le comité de suivi du projet pourra se réunir pour
prendre des décisions importantes en tant que de besoin. Ce type de réunion peut
nécessiter la présence du chef de projet qui en sera averti une semaine à l’avance et pourra
se voir demander d’amener une présentation de certains points, pour aider le comité de suivi
à arbitrer / acter certains choix de détail par exemple. Ces réunions sont décidées à la
demande d’une des parties.
Tous les choix structurants devront être présentés par le titulaire à la personne publique (en
réunion de suivi ou de manière distincte), avec les différentes options possibles ; la personne
publique formalisera son choix.
Le compte rendu d’avancement est rédigé par le titulaire tous les deux mois. Il présentera :
• le point sur les activités de la période écoulée ;
• un récapitulatif des problèmes rencontrés ;
• les activités prévues pour la période suivante ;
• les décisions pour les problèmes non urgents et qui n’ont pas été traités dés leur
apparition ;
• la vérification du planning.
Le chef de projet du titulaire est présent aux suivis d’avancement, éventuellement
accompagné d’un expert lorsqu’une thématique forte le requiert.
7.4 Autres réunions

Le titulaire est également amené à participer, sur simple demande formulée au moins une
semaine à l’avance, aux réunions du GT5 (traitement informatique des données) et aux
réunions de travail avec le coordinateur du projet (titulaire du lot 1) ou occasionnellement
avec d’autres intervenants techniques (titulaires des lots 2, 3 et 4).
7.5 La logistique
La plate-forme technique (machines serveur et infrastructure de stockage) cible sera fournie
par le MEDD et installée sur le site d’hébergement final (dans les locaux de l’INERIS à Verneuil
en Halatte dans l’Oise).
Les développements seront réalisés dans les locaux du titulaire. Cependant, compte-tenu de
l’infrastructure technique de la plate-forme cible et de sa volumétrie globale, un accès
sécurisé sera proposé au titulaire durant toute la durée du marché afin que le titulaire
implémente régulièrement les développements sur la plate-forme B. Le titulaire intègrera
31
dans sa proposition tous les déplacements prévus sur le site d’hébergement de la plate-
forme B (dans les locaux de l’INERIS à Verneuil en Halatte dans l’Oise).
7.6 Maintenance
La proposition intègrera une maintenance pour une durée de deux ans à compter de
l’achèvement de la phase 2.
Le titulaire s’engage :
• à implanter son application sur les serveurs choisis par le Ministère pour accueillir le
futur INS ;
• à intervenir pour dépannage dans un délai de 24 heures lors de problèmes liés à
l'application ;
• à assurer une assistance téléphonique (jours ouvrables de 8h à 18h) aux personnes
désignées comme administrateur (a minima 2 interlocuteurs).
Le titulaire devra prévoir un outil de diagnostic des pannes et erreurs courantes susceptibles
de survenir pendant l’utilisation permettant un dépannage plus efficace.
La proposition devra comporter les meilleures conditions de prix pour un forfait d’intervention
de 15j/an pour la réalisation de petites évolutions.
Ce forfait prendra effet à compter de la mise en ligne définitive du site et pourra être utilisé
sur bons de commande pendant trois années consécutives.
La personne publique se réserve la possibilité de ne pas bénéficier de la totalité de ce
forfait, qui le cas échéant, ne fera pas l’objet d’une facturation pour la part non
consommée.
Dans le cas où les modifications importantes ou les évolutions ultérieures seraient assurées
par le titulaire, des demandes de prestations ponctuelles pourront avoir lieu. Cependant, à
l’issue de la prestation, l’Administration devra être en mesure d’effectuer elle-même des
évolutions de l’outil.
7.7 Organisation de la communication
7.7.1 Mise à disposition de la messagerie

Les envois par e-mail ne pourront en aucun cas dépasser 4 Mo, limite technique au MEDD.
7.7.2 Journal de projet

Le titulaire tiendra un journal de projet (site projet Internet par exemple), dans lequel seront
consignés, les faits marquants du projet ainsi que les comptes rendus de toutes les réunions.
Ce journal sera consultable par la maîtrise d’ouvrage.
7.7.3 Autres
Le titulaire tiendra à la disposition de la maîtrise d’ouvrage la liste de tous les documents
produits sur le projet.
Un annuaire de toutes les personnes intervenant sur le projet avec leurs coordonnées dans
l’entreprise sera mis à la disposition du MEDD.
32
8 Conditions spécifiques de réalisations
8.1 Exigences d’architecture applicative

Les développements respecteront les normes et standards définis dans le document [DR1].
Le document « Étude d’architecture pour l’Inventaire National Spatialisé » en pièce jointe est
la production du titulaire de la phase d’analyse (lot n°1). Il est fourni à titre indicatif et a fait
l’objet d’une analyse approfondie.
Le choix technologique sera dûment argumenté, notamment en ce qui concerne la base de
données - centre névralgique du présent projet, en prenant en compte les différents
scénarios associés, en terme :
• de dimensionnement et d’optimisation ;
• d’administration ;
• de performances et de montée en charge ;
• d’initialisation et de reprise des données en cas de crash.
L’application déclinera une conception en couches (données, métier, présentation). La
conception respectera une conception UML.
8.2 Développements informatiques

Le titulaire dans sa réponse devra proposer les outils et les développements informatiques
nécessaires à la mise en uvre des fonctionnalités décrites ci avant, en respectant les
contraintes énoncées.
Le Ministère chargé de l’environnement est le propriétaire des développements spécifiques
réalisés dans le cadre de cette consultation. Le titulaire devra fournir tous les codes sources
et les documents de travail utilisés lors du projet.
Dans le cadre de la mise en uvre du « référentiel général d’interopérabilité » induit par
l’Ordonnance n°2005-1516 du 8 décembre 2005 relative aux échanges électroniques entre
les usagers et les autorités administratives et entre les autorités administratives, il est
demandé au titulaire de prendre en compte au niveau des développements, autant que
de besoin, les documents techniques qui seront disponibles.
Les informations relatives à ce référentiel sont disponibles sous le lien suivant :
http://www.vitamin2.adae.gouv.fr/ministeres/domaines_d_expertise/architecture_fonctio/p
ublic/rgi/.
8.3 Conservation des données et volumétrie

Le MEDD souhaite que soient conservées sur la plate forme B trois années :
• l’année de référence ;
• l’année la plus récente N ;
• l’année N-1 ;
• ainsi qu’une année de travail supplémentaire pour le rechargement possible d’une
année archivée.
Les autres années seront conservées en dehors de cette plate-forme (archivage).
Le titulaire intégrera dans sa réponse technique et méthodologique un processus
d’archivage ainsi qu’un processus de réimplantation d’une année archivée.
33
L’ensemble des données du site de production sera contenu dans une base de données
pour un volume annuel estime à 3 To. Le logiciel de base de données devra être choisi par le
titulaire en prenant en compte les spécificités du projet en termes de volumétrie de données
et de fonctionnalités SIG.
8.4 Fréquentation
La fréquentation attendue est de 10000 visiteurs par mois en période d’activité normale. Le
système devra néanmoins pouvoir absorber les périodes de crise, environ 30000 visiteurs par
mois.
Les accès simultanés à prévoir sur la plate-forme cible sont :
• 20 utilisateurs simultanés pour les utilisateurs de type « accès libre » ;
• 2 utilisateurs simultanés de type « mission de service public » ;
• 1 utilisateur de type « administrateur ».
8.5 Contraintes de service

La disponibilité du système devra être maximale durant les heures ouvrées (c'est-à-dire 9h-
18h en France métropolitaine).
En cas de panne quelle que soit l’heure, une alerte devra être envoyée aux administrateurs
du système. En cas de panne, le titulaire détaillera la procédure automatique (ou semi-
automatique) permettant de remonter le système. Les opérations de restauration du service
devront être simplifiées et sécurisées au maximum. En cas de panne en dehors des heures
ouvrées et si la procédure de reprise après panne échoue, le service sera rendu inaccessible
jusqu’à l’intervention de l’exploitation.
Pour des problèmes simples, le titulaire prévoira des procédures simplifiées qui, selon la
gravité des problèmes, ne nécessiteront pas le déplacement d’un membre de l’équipe
informatique et permettra à l’exploitant d’effectuer certaines manipulations via des batchs
ou exécutables par exemple.
8.6 Appropriation par l’INERIS

La solution cible sera hébergée et administrée par l’INERIS.
Les administrateurs du système devront pouvoir intervenir sur tous les éléments du système et
par conséquent devront s’être au préalable approprié la solution dans son intégralité. Le
transfert de connaissance et de compétences est un aspect majeur du projet. Le titulaire
prendra en compte dans sa réponse cette appropriation par l’INERIS à chaque étape clef du
projet et notamment lors de la livraison d’une évolution majeure, lors de l’installation initiale
de la plate-forme B, des tests de pré-recette, de l’administration de la plate-forme.
8.7 Langue de travail et des documents

Tous les produits livrés seront rédigés en français. Le titulaire devra être à même de participer
aux réunions de travail en français et à échanger avec les différents partenaires en français
(rédaction de notes techniques, communications orales).
Option n°X4 : une version anglaise du site Internet sera proposée sur la base d’un prix par
1000 mots traduits.
8.8 Autres exigences

Le titulaire précisera en outre dans sa proposition les références similaires en termes de
technologies, de périmètre fonctionnel ou de travaux.
34
En termes de licences logicielles, les machines seront toutes équipées d’un système
d’exploitation (Linux ou Microsoft Windows 2003 à définir). La machine cible hébergeant la
base de données de l’inventaire sera équipée des licences appropriées pour le système de
base de données choisi par le titulaire.
Les éventuels coûts de licences supplémentaires devront figurer dans la réponse financière
du titulaire.
9 Modalités de recette
9.1 Principes généraux d’organisation

Les livraisons se feront de préférence en cascade, c’est-à-dire par sous-ensembles cohérents
et avec étalement dans le temps. Un mode de développement itératif, permettant de voir
rapidement un résultat et de le comparer aux besoins avant d’aller plus loin, sera considéré
comme un gage de robustesse pour l’application finale. Un mode de développement en
tunnel, où le produit des développements précéderait de peu la recette finale, est exclu.
En fonction des livraisons, le titulaire ou l’exploitant, assurera le déploiement (installation) des
éléments constitutifs de chaque module livré.
Chaque livraison sera accompagnée d’un plan de tests spécifique. Elle fera alors l’objet
d’une revue de pré-recette, qui aura pour objectif de vérifier que toutes les fournitures
prévues sont livrées et que leur état permet de procéder à la recette.
Le titulaire s’engage à apporter les modifications qui s’imposent suite à la détection
d’anomalies lors des phases de pré-recette.
La revue de pré-recette se conclura par un PV de recette qui, s’il ne fait pas l’objet de
réserves de la part du maître d’ouvrage, permettra de considérer les livraisons comme
réceptionnées.
La recette sera réalisée par le maître d’ouvrage et aura lieu dans ses propres locaux.
9.2 Recette définitive de l’application et garantie

Si aucune fiche anomalie n’est émise pendant la revue de pré-recette, la réception
définitive sera prononcée via un PV de réception qui fixera la date à partir de laquelle
débutera le délai de garantie.
Le titulaire prévoira une garantie d'un an pendant laquelle il assurera la maintenance
corrective sans que ceci n’entraîne de coût supplémentaire pour le maître d'ouvrage.
Lorsqu'une anomalie sera détectée, elle sera consignée par le maître d'ouvrage dans une
fiche d'observation en précisant si l'anomalie est bloquante.
Après analyse de l'anomalie, le titulaire précisera son délai d'intervention et de réalisation.
Pendant cette période, le titulaire s’engage à intervenir dans un délai de 48 heures pour les
anomalies bloquantes identifiées par le maître d’ouvrage.
Les anomalies non bloquantes seront regroupées par lots, puis transmises au titulaire pour
correction. Ces lotissements seront réalisés par la maîtrise d’ouvrage selon un rythme maximal
d’un par mois.
35
10 Assurance qualité
10.1 Plan d’Assurance Qualité

Le titulaire rédigera un Plan d’Assurance Qualité dès la phase d’initialisation du projet. Ce
document de référence sera validé par le maître d’ouvrage et révisé le cas échéant par le
titulaire si l’organisation du projet le nécessite.
Le Plan Assurance Qualité contribue à :
• assurer la maîtrise des processus de conduite et de gestion de projet, des procédés
de réalisation, de la qualité de la solution ;
• faciliter la communication au sein de l’équipe constituée pour le projet ;
• maîtriser les délais et les coûts du projet par la mise en uvre d’indicateurs et de
points de contrôle ;
• donner une visibilité du projet à la maîtrise d’ouvrage, au titulaire et éventuels
intervenants externes.
Il couvre la totalité des prestations pour la durée du projet et est applicable à l’ensemble des
intervenants.
Ad minima, la PAQ sera composé :
• des principes d’organisation de l’équipe du titulaire ;
• des principes d’organisation des activités entre le titulaire et le maître d’ouvrage ;
• du découpage organisationnel du projet ;
• des étapes du projet et la description des prestations réalisées ;
• des différents processus de production et d’assurance qualité ;
• des mécanismes de mise en place d’une nouvelle version de base et notamment le
basculement d’une année sur l’autre.
10.2 Démarches qualité

Les démarches qualité s’inscriront dans le contexte pragmatique du MEDD, où la qualité se
doit d’être présente à toutes les étapes du projet, notamment lors des différentes revues.
Rappelons qu’une revue est un examen technique de l’état du projet, qui permet de vérifier
la cohérence de l’ensemble documentaire, sa conformité très détaillée par rapport aux
besoins et de s’assurer de la bonne marche du projet.
Ces revues permettront notamment de vérifier que chaque sous-système mis en place
répond aux exigences qualité suivantes :
• capacité fonctionnelle : ensemble d’attributs portant sur l’existence d’un ensemble
de fonctions et leurs propriétés données. Les fonctions sont celles qui satisfont aux
besoins exprimés et implicites ;
• interopérabilité : attributs du logiciel portant sur sa capacité à interagir avec des
systèmes donnés ;
• fiabilité : ensemble d’attributs portant sur l’aptitude du système à maintenir son
niveau de service dans des conditions précises et pendant une période
déterminée ;
36
• possibilité de récupération : attributs du système portant sur ses capacités à rétablir

son niveau de service et de restaurer les informations directement affectées en cas
de défaillance, et sur le temps et l’effort nécessaire pour le faire ;
• facilité d'utilisation : ensemble d’attributs portant sur l’effort nécessaire pour
l’utilisation et sur l’évaluation individuelle de cette utilisation par un ensemble défini
ou implicite d’utilisateurs ;
• maintenabilité : ensemble d’attributs portant sur l’effort nécessaire pour faire des
modifications données ;
• évolutivité : fonctionnelle et technique ;
• exploitabilité : ensemble de mécanismes et processus facilitant et garantissant la
bonne gestion (nominale et exceptionnelle) de l’application en production.
10.3 Documentation
Les documents peuvent être classés en trois catégories :
• gestion de projet ;
• technique ;
• utilisation et exploitation.
Les documents seront identifiés par un numéro qui apparaîtra sur chaque page. A chaque
évolution sera associée une fiche d’évolution mentionnant toutes les pages concernées par
les modifications.
Tous les documents seront livrés au format Microsoft Word 97/2000.
10.4 Gestion des configurations

Le Titulaire gèrera les différentes versions et/ou révisions.
On appellera version, un état de l’application qui satisfait les fonctionnalités commandées à
un instant donné par la personne publique.
On appellera révision, un sous état de l’application qui satisfait à un moment donné à un
niveau de qualité technique.
Le principe d’identification retenu est le suivant : <Nom de l’application><N°de
version><N°de révision>. Une modification des spécifications entraîne une modification de
version. Une modification de conception ou de code entraîne un changement de révision.
Quand on change de version, on change de révision.
Les éléments gérés en configuration sont les suivants :
• les sources ;
• les versions successives de la base de données ;
• les exécutables ;
• les procédures ;
• la documentation ;
• les jeux d’essais ;
• les résultats de tests ;
• les fiches de demandes de modifications.
37
Chaque élément de configuration devra être rattaché à une ou plusieurs versions de bases
de données dont il dépend. Le traitement des modifications sera intégré au système de
gestion de configuration afin de retrouver la liste de toutes les modifications effectuées sur
une version ainsi que les raisons de ces modifications.
38
Annexe I
Liste des 38 polluants directement issus des protocoles de calcul.
Nom du polluant Formule

Monoxyde de carbone CO
Oxydes d’azote NOx
Dioxyde de soufre SO2
Composés Organiques Volatils Non COVNM
Méthaniques
Ammoniac NH3
Particules totales en suspension TSP
Dioxyde de carbone CO2
Méthane CH4
Oxyde nitreux N2O
9 espèces d’hydrofluorocarbures HFC-125; HFC-23; HFC-152a; HFC-143a;
HFC-227ea; HFC-365mfc; HFC-43-
10mee; HFC-134a; HFC32
7 espèces de perfluorocarbures C2F6; CF4; C6F14;
C5F12; c-C4F8; C3F8; C4F10
Hexafluorure de soufre SF6
Mercure Hg
Arsenic As
Cadmium Cd
Plomb Pb
Chrome Cr
Cuivre Cu
Manganèse Mn
Nickel Ni
Sélénium Se
Zinc Zn
Hydrocarbures Aromatiques Polycycliques HAP
Dioxines et Furanes PCDD/F
39
Annexe II
Espèces spéciées.
Familles Polluant génériques Spéciation (S)/ Espèces Spéciées

agrégées Agrégation (A)
CO, SO2, NH3, -
NOx, S 2 espèces : NO et NO2
COVNM S Environ 500 espèces
TSP S spéciations
granulométrique (PM2.5
et PM10) et chimique
HFC 9 Espèces HFC A
PFC 7 Espèces PFC A
PRG Gaz à effet de serre : -
CO2, CH4 , N2O,
HFC,PFC, SF6
SF6 -
As, Cd, Pb, Cu, Mn, Ni, -
Se, Zn
Cr S 2 espèces : Cr III et Cr VI
Hg S Hg(0), Hg (II) gaz, Hg(II)
particulaire
HAP S 8 espèces réglementées
et “autres”
PCDD/F - Calcul en masse + ITEQ
40

Elaboration Des CCTP

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Elaboration Des CCTP

Загружено:

Авторское право:

Доступные форматы

PROPOSITION DE

en date du 23 novembre 2006 relatif à l’appel d’offre pour

la réalisation du lot 5 de l’inventaire national spatialisé

Le présent C.C.T.P. comprend 40 pages numérotées de 1 à 40 dont 2 annexes

2 Documents applicables et de référence ................................................................................ 6

4 Objet du marché ..................................................................................................................... 7

6 Description détaillée de la prestation ................................................................................... 10

7 Organisation et gestion de projet .......................................................................................... 30

8 Conditions spécifiques de réalisations .................................................................................. 33

9 Modalités de recette .............................................................................................................. 35

10 Assurance qualité ................................................................................................................... 36

1.1 Description du projet

1.2 Objectifs poursuivis

2 Documents applicables et de référence

2.1 Documents applicables

Document Description Version Auteur Date

Dossier d’architecture logicielle et

2.2 Documents de référence

Document Description Version Auteur Date

CCTP_ INS_20050629.doc : CCTP

Protocoles techniques intermédiaires

Inventaire National Spatialisé des émissions de polluants atmosphériques

Le rôle de la plate forme A est de compiler l’ensemble des données

La plate-forme B assure tous les processus de traitement (spéciation,

Une « étude » correspond à l’ensemble des traitements effectués sur les

Le « scénario » est la partie de l’étude consistant à modifier des

Le « post-traitement » est la partie de l’étude consistant à spécifier le

Outil de prévision et de cartographie de la qualité de l’air en France et en

Modèle numérique de simulation du transport et de la chimie des

Valeur relative des émissions de différents composés à l’intérieur d’une

4.1 Périmètre de la prestation

o alimentation du système PREV’AIR (cf. chapitre 6.2) ;

Les protocoles opérationnels, précisant notamment les types de données de sortie de la

Constitution de la base de données de l’INS

Alimentation du système PREV’AIR

Site Internet de l’INS

Gestion des scénarios

Pour l’ensemble des modules réalisés, le titulaire s’engage à livrer :

6 Description détaillée de la prestation

6.1 Mise en place de la plate-forme B

6.1.2 Les utilisateurs de la plate-forme B

Une description plus détaillée est donnée dans le tableau suivant :

Utilisateur Applications types Produits

§ Information et § Cartes au km² sur une zone déterminée par

1 Présentés sous forme de tableaux .csv (fichiers délimités) par exemple.

Utilisateur Applications types Produits

§ Niveau précédent + § Bases de données d’activité (si non

§ Niveau précédent § Accès total sans clause de confidentialité

6.1.3 Les fonctions de la plate-forme B

6.1.3.1 Traitement et formatage des résultats

6.1.3.2 Stockage et diffusion des résultats

6.1.3.2.1 Données diffusées

6.1.3.2.2 Stockage des résultats

6.1.3.2.2.1 Nature et taille des données stockées

6.1.3.2.2.2 Durée de stockage temporaire

l’utilisateur aura connaissance par l’envoi du courriel d’information de la mise à disposition

6.1.3.2.3 Affichage des résultats

6.1.3.2.3.1 Affichage des valeurs de sortie de la plate-forme B

6.1.3.2.3.2 Affichage de couches cartographiques complémentaires

couche cartographique selon un format compatible avec le SIG de la plate-forme B, par le

6.1.3.2.3.3 Fonctions de navigation

6.1.3.2.4 Diffusion des résultats

6.2 Alimentation du système PREV’AIR

6.2.1 Le système PREV’AIR et le modèle CHIMERE