DNE B2-3 : QUALITE,

METHODES ET OUTILS

CADRE DE COHERENCE TECHNIQUE

DU MINISTERE DE l’EDUCATION NATIONALE

Dernière mise à jour du document : 17/05/2016

 HISTORIQUE DU DOCUMENT

Version Date Auteur Modifications

1.0 13/01/2011 S.Degoul (Clermond-Ferrant) Création du document
1.1 21/07/2011 S.Degoul (Clermond-Ferrant) Reprise du document déposé sur
le médiawiki de la forge par
l'équipe de Versailles
1.2 06/09/2011 C. Bracchi-Cabannes Reformulation des règles pour
(Toulouse) appliquer les niveaux d’obligations
au lieu de l’utilisation de la
colonne « oblig. »
1.3 28/11/2014 N. CHAIGNEAU (DNE B2-3) Réactualisation du document avec
les membres de l’OTDA.
1.4 09/01/2015 R.STEPHAN (MODA) - Ajout numérotation des règles
- Réorganisation du document
- Ajout/Suppression de règles
1.5 08/06/2015 N.CHAIGNEAU (DNE B2-3) Synthèse des règles identifiées et
commentées par l’OTDA. Remise
en forme du document.
1.5.1 16/06/2015 N.CHAIGNEAU (DNE B2-3) Prise en compte des remarques de
l’OTDA avant publication pour
appel à commentaire.
1.5.2 25/06/2015 N.CHAIGNEAU (DNE B2-3) Prise en compte des remarques
lors de l’appel à commentaire.
1.5.4 23/12/2015 N.CHAIGNEAU (DNE B2-3) Mise à jour des règles validées par
l’OTDA le 08/10/2015
1.5.5 17/05/2016 N.CHAIGNEAU (DNE B2-3) Ajout de la mention relative à la
prise en compte des règles liées à
la production.
Mise à jour de la pagination du
document.
 SOMMAIRE

1. INTRODUCTION .........................................................................................................................................................4
1. APPLICATION DES RÈGLES .................................................................................................................................................4
2. NIVEAUX D'OBLIGATION ...................................................................................................................................................4
3. NON-RESPECT DES RÈGLES ................................................................................................................................................4
4. GRILLE DE LECTURE ..........................................................................................................................................................5
2. ERGONOMIE / POSTE CLIENT ...............................................................................................................................6
1. CHARTE GRAPHIQUE [R1] .................................................................................................................................................6
2. MULTI-NAVIGATEURS [R2] ...............................................................................................................................................6
3. NAVIGATION [R3] .............................................................................................................................................................6
3. INFRASTRUCTURE ....................................................................................................................................................7
1. BASE DE DONNÉES [R6] ....................................................................................................................................................7
2. SERVEUR D'APPLICATION [R8] ..........................................................................................................................................7
3. ENVIRONNEMENT [R9] ......................................................................................................................................................7
4. INTEROPÉRABILITÉ .................................................................................................................................................8
1. INTEROPÉRABILITÉ [R10]..................................................................................................................................................8
5. DÉVELOPPEMENT .....................................................................................................................................................9
1. GESTION DE SOURCES [R11] .............................................................................................................................................9
2. DESIGN PATTERN [R12] ....................................................................................................................................................9
3. COMPOSANTS [R13] ..........................................................................................................................................................9
4. COMPOSANTS WEB [R14] .................................................................................................................................................9
5. JAVASCRIPT [R15] ............................................................................................................................................................9
6. QUALITÉ DU CODE [R17]...................................................................................................................................................9
7. GESTION DES EXCEPTIONS [R22].....................................................................................................................................10
8. JOURNALISATION APPLICATIVE [R23] .............................................................................................................................10
9. COMPILATION / PACKAGING DE L'APPLICATION [R24] ....................................................................................................10
6. TESTS ...........................................................................................................................................................................11
1. TESTS [R25] ....................................................................................................................................................................11
7. SÉCURITÉ ...................................................................................................................................................................12
1. AUTHENTIFICATION [R26] ..............................................................................................................................................12
2. MESURES DE PROTECTION [R27] .....................................................................................................................................12
3. GESTION DES MESSAGES D’ERREUR TECHNIQUES [R28] ..................................................................................................12
8. SUPERVISION ............................................................................................................................................................13
1. TEST DE LA DISPONIBILITÉ DE L'APPLICATION [R29] .......................................................................................................13
9. LIVRAISON .................................................................................................................................................................14
1. DÉPLOIEMENT [R31] .......................................................................................................................................................14
10. DOCUMENTATION...................................................................................................................................................15
1. DOCUMENTATION LIÉE À LA CONCEPTION D’UNE APPLICATION [R32] ............................................................................15

________________________

page 3 / 15
1. Introduction

Le présent document, dans sa version 1, adresse les métiers du développement du ministère de

l’Éducation Nationale, de l’Enseignement Supérieur et de la Recherche. Un document plus complet,
comprenant les règles liées à l'industrialisation, à la production et à observer par les équipes de
développements, d'intégration et de diffusion, va suivre. Il fera l’objet d’une version 2 du présent
document.

1. Application des règles

Les règles présentées dans ce document s'appliquent à tout projet national concernant des
applications web développées en Java, quelle que soit la maîtrise d'ouvrage et quelle que soit la
maîtrise d'œuvre, notamment dans le cas d'externalisation des développements.
En cas d'externalisation du développement, lors du démarrage de la mission, et pour réaliser la
prestation de prise de connaissance, des compléments seront apportés au titulaire: Dossier
d'architecture technique du domaine, site interne à l'éducation nationale précisant les normes de
développement à respecter (utilisation de JUnit, paramétrage PMD, checkstyle, bonnes pratiques,
etc…).

2. Niveaux d'obligation
Les règles présentées dans ce document ont différents niveaux d'obligation dont l’acception,
selon une traduction française de la RFC 2119 est la suivante :
• DOIT : ce mot, ou le terme « EXIGÉ », signifie que la définition est une exigence
absolue de la spécification.
• NE DOIT PAS : cette expression signifie que la définition est une prohibition absolue de
la spécification.
• DEVRAIT : ce mot, ou l'adjectif « RECOMMANDÉ », signifie qu'il peut exister des
raisons valables, dans des circonstances particulières, pour ignorer cet item particulier,
mais les conséquences doivent être comprises et pesées soigneusement avant de
choisir une voie différente.
• NE DEVRAIT PAS : cette expression, ou l'expression « NON RECOMMANDÉ »,
signifient que la définition est prohibée. Il peut toutefois exister des raisons valables,
dans des circonstances particulières, quand le comportement particulier est acceptable
ou même utile, de ne pas suivre cette recommandation. Mais les conséquences doivent
être comprises et le cas soigneusement pesé.
• PEUT : ce mot, ou l'adjectif « FACULTATIF », signifie qu'un item est vraiment
facultatif. Une équipe peut inclure l'item parce qu'une application particulière l'exige ou
parce qu'elle estime qu'il améliore l'application tandis qu'une autre équipe peut omettre
le même item.

3. Non-respect des règles

En cas de non-respect des règles, toute l'équipe de développement interne ou externe devra
spécifier et justifier les points suivants :
• Les circonstances et justifications de non-respect d'une règle RECOMMANDÉE (ou DEVRAIT),
• les circonstances et justifications de non-respect d'une règle NON RECOMMANDÉE (ou NE
DEVRAIT PAS),
• les justifications des exceptions à toute règle obligatoire (DOIT ou NE DOIT PAS); et dans ce
dernier cas, l'avis du MEN doit être demandé et faire l’objet d’une validation par la
CAU (Commission d’Architecture et d’Urbanisme) et par l’OTDA (Observatoire des
Technologies en Développement d’Application).
Toutes les justifications devront être mentionnées dans le DAT (Dossier d’Architecture Technique).
On notera néanmoins qu'il n'est pas interdit d'enfreindre certaines règles de manière ponctuelle,
mais que le non-respect fréquent et systématique à une règle est à proscrire.

page 4 / 15
 4. Grille de lecture
Les outils (PMD, Checkstyle et le code formatter) intégrés à Eclipse, permettront de contrôler
que le respect des règles dans la mesure où ils autorisent la vérification. Pour les règles non outillées,
un contrôle sera fait par une lecture du code. Le paramétrage de ces outils sera celui défini dans un
socle technique interne au ministère accessible par le titulaire lors de la prestation de prise de
connaissance de l'environnement technique. Maven sera paramétré pour lancer un maximum de
contrôle à chaque « build ».
Il est de la responsabilité des développeurs de respecter ces normes même si les outils ne
peuvent pas les aider dans ce travail.

page 5 / 15
2. Ergonomie / Poste Client

1. Charte Graphique [R1]

Règle Description
R1.1 Le projet DOIT respecter une charte graphique.
La charte graphique définit les principes de navigation, l'aspect des écrans et les bonnes
Précision pratiques ergonomiques à respecter (ex: pas d’ascenseurs horizontaux, résolution
R1.1 minimale). La charte graphique peut être différente selon les utilisateurs concernés par
l'application (1er degré, 2nd degré, gestionnaires, etc…).

2. Multi-navigateurs [R2]

Règle Description
L'interface web DOIT respecter les préconisations de compatibilité des
R2.1
navigateurs de l'OTDA.
Les nouveaux projets d'application web du MEN doivent/peuvent subir une phase de
qualification pour les navigateurs suivants :

- Qualification obligatoire pour Firefox et Chrome dans leurs dernières versions au

moment de la qualification, dans le cadre d'application dont l'usage est interne (à savoir
l'administration centrale, les rectorats, les directions des services départementaux de
l'Education nationale).

Précision - Qualification facultative pour Internet Explorer dans sa dernière version compatible
R2.1 avec l'OS cible des postes de travail des utilisateurs finaux, dans le cadre d'application
dont l'usage est interne (à savoir l'administration centrale, les rectorats, les directions
des services départementaux de l'Education nationale).

- Qualification obligatoire pour Firefox et Chrome et Internet Explorer dans leurs

dernières versions au moment de la qualification, dans le cadre d'application dont
l'usage est à destination du grand public. Dans le cas du navigateur Internet Explorer la
qualification s'impose pour les dernières versions compatibles avec les OS Windows XP
et suivants.

3. Navigation [R3]

Règle Description
R3.1 Les standards HTML, XHTML DOIVENT être respectés.

page 6 / 15
3. Infrastructure

1. Base de données [R6]

Règle Description
R6.1 Le système de gestion de base de données PostgreSQL ou DB2
DOIVENT être utilisés.
Précision Le type et la version de base de données devra respecter les préconisations du bureau
R6.1 des infrastructures techniques de la DNE (DNE B1-1).
R6.2 Un login spécifique DOIT être utilisé pour les accès à la base de
l'application et ce login n'a que les droits nécessaires pour le
fonctionnement de la base de l'application.

2. Serveur d'application [R8]

Règle Description
R8.1 Les serveurs d’applications JBOSS ou Weblogic DOIVENT être utilisés.
Précision La version du serveur d'application devra respecter les préconisations du bureau des
R8.1 infrastructures techniques de la DNE (DNE B1-1).

3. Environnement [R9]

Règle Description
R9.4 La préconisation de l’OTDA sur l’encodage des caractères DOIT être
respectée.
L’OTDA a validé les préconisations suivantes en termes d’encodage :

COUCHE ENCODAGE
Précision
DB2 ISO-8859-15
R9.4 DAO
Autres BDD (PostgreSQL, MySQL…) UTF8
Service UTF8
Web UTF8

page 7 / 15
4. Interopérabilité

1. Interopérabilité [R10]

Règle Description
R10.1 Le Référentiel Général d’Interopérabilité (RGI) DOIT être respecté.
Précision Une synthèse des règles du RGI est disponible dans la Malette (Document NFR ; onglet
R10.1 RGI)

page 8 / 15
5. Développement

1. Gestion de sources [R11]

Règle Description
R11.1 Un gestionnaire de sources DOIT être utilisé.
il est recommandé d'utiliser GIT pour les nouveaux projets avec TyForge (forge logicielle
Précision du MEN) en dépôt maître, à défaut Subversion reste utilisable comme alternative si la
R11.1 mise en œuvre de GIT n'est pas réalisable ou pour les anciens projets pour lesquels une
migration s'avèrerait trop coûteuse.
R11.2 La Forge TyForge DOIT être utilisé pour héberger les projets.

2. Design Pattern [R12]

Règle Description
R12.1 Les standards J2EE pour les design Pattern DOIVENT être respectés.
R12.2 Les normes pour la mise en place d'un MVC DOIVENT être respectées.

3. Composants [R13]

Règle Description
R13.1 La solution de gestion d'identité RSA Access Manager DOIT être utilisée.
Si la solution de gestion d'identité RSA Access Manager n'est pas applicable à la
Précision
population ciblée une description détaillée du processus d'authentification et de gestion
R13.1
d'identité doit être spécifiée.

4. Composants Web [R14]

Règle Description
R14.1 Les fichiers CSS DOIVENT être utilisés afin de faciliter la modification du
style de l'application.

5. JavaScript [R15]

Règle Description
R15.4 Les contrôles JavaScript DOIVENT être doublés côté serveur
d'application.

6. Qualité du code [R17]

Règle Description
R17.1 Le référentiel de qualité du code (lien) DEVRAIT être respecté.

page 9 / 15
 7. Gestion des exceptions [R22]

Règle Description
R22.2 La problématique des exceptions DOIT être abordée dès le début de la
phase d'implémentation.
R22.3 Toutes les erreurs susceptibles de se produire dans l'application
DOIVENT être gérées.
R22.4 Le message attaché à une exception DOIT être suffisamment
représentatif pour comprendre l'erreur qui s'est produite et permettre de
localiser l'erreur dans le code le plus rapidement possible.
R22.14 On DOIT utiliser un outil de journalisation (logging) au lieu d'imprimer la
stacktrace.

8. Journalisation applicative [R23]

Règle Description
R23.8 Lors d'une erreur côté serveur, l’application DOIT réafficher les valeurs
saisies par l'utilisateur.
R23.9 Pour les erreurs 404, l'utilisateur DOIT être redirigé vers une page
d'erreur prédéfinie.

9. Compilation / Packaging de l'application [R24]

Règle Description
R24.1 Maven DOIT être utilisé systématiquement pour compiler l'application,
exécuter les tests de non régression et fabriquer les artefacts.
Maven est un outil multiplateforme open source gérant le processus de build Java.
Il permet entre autres :
• La compilation de sources,
• La création d'archive jar /war,
Précision
• Gestion dépendances de l'application,
R24.1
• La génération de javadoc,
• Le contrôle du code via un plugin PMD par exemple
• D'automatiser l'exécution des tests unitaires
• et bien d'autres fonctionnalités.

page 10 / 15
6. Tests

1. Tests [R25]

Règle Description
R25.2 Les tests unitaires DOIVENT systématiquement être lancés afin de
vérifier la non régression de l'application.
R25.3 Les tests de montée en charge (TMC) DEVRAIENT être réalisés avant
une mise en production.
Précision Les tests de montée en charge doivent être effectués sur une infrastructure conforme
R25.3 au DAT validé par DNEB1-1.
R25.4 Les tests d'audit de sécurité de code DEVRAIENT être réalisés avant une
mise en production.

page 11 / 15
7. Sécurité

1. Authentification [R26]

Règle Description
R26.1 Les consignes relatives à la gestion de l'identité DOIVENT être
respectées pour toutes les personnes dont l'identité numérique est
fournie par l'éducation nationale.
Précision La prise en compte de la gestion des habilitations sera exposée au titulaire lors de la
R26.1 mission de prise de connaissance fonctionnelle.
R26.2 Chaque application DOIT avoir un dossier définissant sa politique
d'habilitation.

2. Mesures de protection [R27]

Règle Description
R27.1 Le Référentiel Général de Sécurité (RGS) [lien] DOIT être respecté.

3. Gestion des messages d’erreur techniques [R28]

Règle Description
R28.1 Les traces d’erreurs techniques NE DOIVENT PAS être affichées à
l’utilisateur de l’application.
Précision Elles doivent être remplacées par un message d’erreur générique et l’identifiant de
R28.1 l’erreur technique.

page 12 / 15
8. Supervision

1. Test de la disponibilité de l'application [R29]

Règle Description
R29.1 Il DOIT y avoir une page de tests pour l'outil de supervision mis en
place.
R29.2 Le composant RACVISION [lien] DOIT être utilisée comme page de tests.

page 13 / 15
9. Livraison

1. Déploiement [R31]

Règle Description
R31.4 Les données de configuration de l’application DOIVENT pouvoir être
externalisées dans un répertoire accessible au serveur d’application.
R31.5 Une documentation d'installation DOIT être livrée : Dossier d'Installation
Technique (infrastructure), Dossier d'Installation de la Livraison.

page 14 / 15
10. Documentation

1. Documentation liée à la conception d’une application [R32]

Règle Description
R32.2 Le Dossier d’Architecture Technique (DAT) DOIT être livré.
R32.4 Le compendium du management de projet défini par le Ministère de
l'Education Nationale DOIT être appliqué.

--------- Fin du document ---------

page 15 / 15