Ce document présente notre démarche qualité

1. V1.0 du 14/05/2009
Plan Qualité
Version 1.1 : Le 06/05/2010
1/12

2. V1.0 du 14/05/2009
I. Introduction
Le plan qualité s’intègre dans la démarche qualité générale de l’entreprise de la manière suivante :
- Les valeurs : définition des valeurs de l’entreprise sur lesquelles vont s’adosser le PAQ
- Le plan d’assurance qualité (PAQ) : définit quel processus IDfr met en place pour respecter le plan qualité
- Le plan qualité par pôle : établit les règles que tout le monde doit suivre pour aboutir à un projet de qualité
Notre « démarche d’assurance qualité » consiste à prévenir systématiquement et méthodiquement tout
dysfonctionnement source de non-qualité ; c’est le passage d’une logique curative à une logique préventive des
erreurs.
Principe de base :
Ce document décrit donc notre méthodologie générale qui vise à créer la structure permettant de limiter les défauts
(de planning, de publication de bug, de fuite), mais également permettant d’améliorer nos points forts.
Chacun à son échelle joue un rôle dans la qualité globale de nos projets. Il appartient donc à chacun de respecter ces
règles.
2/12

3. V1.0 du 14/05/2009
II. Notre métier et notre savoir-faire
Présentation
IDfr, une nouvelle ID d’internet
Notre métier est de conseiller nos clients et de développer des applications clients/serveurs qui répondent au mieux,
d’une part à la cible de nos clients (Internautes, intranautes, mobinautes, …), et d’autre part à notre client.
Pour ce faire, nous avons établi et nous maintenons un observatoire du comportement des internautes, dans le but de
mieux connaître et mieux comprendre les attentes et les usages des internautes. Bien connaître les habitudes permet
en effet de mieux y répondre.
Méthode de gestion d’un projet
La méthodologie de gestion de projet que nous utilisons est une évolution entre la méthode en V (qui est trop rigide
pour des projets trop fluctuants), et la méthode Agile (qui est très orientée long développement).
Vocabulaire
• Rétro-planning : planning prévisionnel décrivant les grandes étapes du projet et leur date probable de
réalisation (utilisation des diagrammes de Grant)
• Il peut y avoir plusieurs versions du site :
o Interne : sur notre serveur de développement. C’est la version sur laquelle nous développons
directement.
o En développement (et pré-dev) : c’est une copie miroir sur le serveur de production de tout
l’environnement (base fichiers)
o En production (et pré-prod) : c’est la version du site qui est visible par les internautes.
• Spécifications fonctionnelles : document qui reprend le cahier des charges initial et le devis, et qui a pour
objectif de définir plus précisément l’ensemble des développements à réaliser. Il annule et remplace, après
signature, le devis et le cahier des charges.
3/12

4. V1.0 du 14/05/2009
III. Les composantes de notre métier
Gestion de projet
Périmètre :
La gestion de projet est une composante importante de notre métier, qui permet de garantir l’ensemble de notre
processus de production. Cette phase débute à la finalisation de l’accord commercial et la signature du contrat avec le
client.
Généralités :
Nous avons décrit ci-dessous toutes les étapes de la gestion d’un projet. À chaque étape, nous décrivons
précisément comment nous travaillons pour atteindre notre objectif de qualité :
Expression du besoin
Analyse du projet
Développement
Test et qualité
Recettage
Ces étapes sont définies ci-après et sont récapitulées dans un fichier de suivi. Ce fichier sera rempli par le chef de
projet et le développeur principal tout au long du projet.
Relation client :
D’une manière générale, les échanges entre client et prestataire donnent lieu au plus de description possible. Toutes
les réunions, tous les échanges téléphoniques (importants) font l’objet d’un compte-rendu écrit, par mail, transmis ou
non au client.
Afin de garantir une parfaite compréhension de nos clients, nous respectons une syntaxe pour les mails : les sujets
des mails doivent commencer par : [contrat|étape] sujet (qui explique clairement l’objet du mail)
Ex : [Dev site | Développement] Passage des développements en pré-production
Concernant les communications internes, nous utilisons la syntaxe pour les sujets de mails : [Client | Projet] sujet (qui
explique clairement l’objet du mail).
Dans tous les mails importants (au moins les mails de changement d’étapes), nous intégrons un tableau récapitulatif
du pourcentage d’avancement des étapes du projet.
4/12

5. V1.0 du 14/05/2009
LES DIFFERENTES ETAPES D’UN PROJET (METHODOLOGIE) :
1- Expression du besoin
Le point de départ est matérialisé par un mail décrivant les 5 étapes du projet, le nom des
interlocuteurs, la création de la liste de diffusion, l’explication de la syntaxe des sujets des mails,
(l’ouverture du compte Idranet), création des URLs projet. Ce mail reprend également la planification
du projet et le tableau récapitulatif du planning.
Une réunion préliminaire au moins pour relire le cahier des charges et le devis : l’objectif de cette
réunion est de bien comprendre le contexte du projet et les objectifs du client (audience,
communication, …). Elle aura souvent lieu chez le client, avec les chefs de projet (client et IDfr), le
commercial, le responsable communication (côté client), et le graphiste.
Établissement des spécifications fonctionnelles, document qui amende le devis et le cahier des
charges initial une fois qu’il a été validé par le client. C’est ce document qui fait référence ensuite, il
doit porter la signature du client. Ce document peut également définir une charte éditoriale (comment
le client doit rédiger ses contenus pour une bonne intégration web ensuite, et comment doivent nous
être transmises les informations).
Etablissement du planning projet et intégration à notre planning (long terme)
La fin de cette étape est marquée par un mail comportant en pièce jointe les spécifications
fonctionnelles, le planning du projet et le tableau de bord.
2- Analyse du projet
Le chef de projet rédige le document d’installation du CMS et fait une réunion de présentation à
l’équipe de développement qui est mobilisée.
Conception de la charte graphique :
Conception de 2 pages (page d’accueil et page intérieure) sur plusieurs chartes (en fonction
du client)
Création des cartes de chaleurs associées (Eyes Tracking)
La première présentation des propositions de charte graphique se fait lors d’une réunion de
présentation, si possible chez IDfr. Si la réunion n’est pas possible, un entretien téléphonique
a lieu aussitôt après l’envoi (prendre un rendez-vous téléphonique avec le chef de projet afin
qu’il ait du temps)
Aller/retour et validation du client
Si nécessaire :
o Déclinaison de tous les écrans
o Aller/retour et validation du client
Conception technique (si nécessaire) avec établissement du MCD de la base
Réévaluation du planning projet et intégration à notre planning (long terme)
La fin de cette étape est marquée par un mail comportant en pièce jointe toutes les maquettes
validées, le planning projet et le tableau de bord.
5/12

6. V1.0 du 14/05/2009
3- Développement
Découpage de la charte graphique
Décomposition en lots de développement et, dans la mesure du possible, faire valider par le client,
étape par étape.
Développements
Publication sur le serveur de développement (voir paragraphe sur la procédure de publication).
Test fonctionnel du chef de projet avant la prépublication.
La fin de cette étape est marquée par un mail d’information du transfert sur le serveur de production
(en pré production), des développements et du tableau de bord.
4- Test et Qualité
Test et contrôle du client
Si l’option a été retenue, après chaque étape (au sens création d’un module), réaliser une validation
de l’ergonomie (avec carte de chaleur) (Eyes Tracking).
Contrôle qualité par le chef de projet (saisie de la grille) et établissement d’un rapport de contrôle
envoyé par mail au client. Ce rapport sera probablement temporaire et comportera des observations
à corriger avant publication, et des observations à corriger plus tard.
Validation du client
Publication
La fin de cette étape est marquée par un mail qui donne la date de publication et met en place la
nouvelle procédure pour les évolutions (création de la préprod) et du tableau de bord.
Annonce à toute l’équipe de la publication via le blog Interne et/ou le site internet IDfr, et intégration
aux documents « Nos références ».
5- Recettage
Immédiatement suite à la publication du site, rédaction d’une recette provisoire. Ce document précise
la publication, les développements publiés et les dates (transmission des éléments par le client et
publication par IDfr). Le client doit ensuite avoir 15 jours à 3 semaines (selon les projets), pour faire
tous les retours et demandes d’évolutions ou corrections de bugs
Le chef de projet doit, sur la base de cette liste de correctifs, préciser ceux prévus dans le contrat, et
ceux qui passeront en maintenance (ou devis complémentaire)
Etablissement d’une recette définitive et signature d’un PV de recette par le client.
6/12

7. V1.0 du 14/05/2009
Charte graphique
Nos chartes graphiques sont créées en fonction des attentes du client et de notre expérience de l’Internet. Elles sont
ainsi toutes différentes, car elles répondent à des besoins différents. Nous faisons particulièrement attention aux
points suivants :
• Contraste des couleurs, pour donner une lecture agréable sur tous les écrans.
• Différence visuelle entre les liens et le texte de contenu. Les liens impliquant un fonctionnement différent sont
affichés de manière différente (ex : les liens vers une définition du glossaire seront différents graphiquement
d’un lien vers une page interne).
• L’attribut « souligné » est réservé aux liens.
• On évitera l’utilisation de caractères majuscules dans la charte graphique, notamment au niveau du menu.
• Tous les textes principaux (menu, titre des pages, sous-titres) seront réalisés en texte HTML (pas en image,
ni en JavaScript).
• La couleur de fond des zones de contenu sera le plus contrastée possible avec la couleur de la police de
texte.
• Pour respecter une cohérence globale et faciliter la compréhension de la navigation, le menu principal est
toujours situé au même endroit sur toutes les pages.
Ergonomie
Un certain nombre d’études de comportement des internautes (Eye-tracking) et le fait qu’il existe encore nombre
d’internautes non aguerris à la navigation, nous ont conduits à respecter les règles suivantes :
• Ne déclencher aucune action non sollicitée (lancer la lecture d’un son, ouvrir un pop-up ou pop-Under
automatiquement, …)
• Les titres des formulaires doivent se situer juste au-dessus du champ de saisie ou sur la même ligne, alignés
à droite.
• Nous limiterons au maximum le nombre de clics nécessaires pour aller d’une information à une autre sur le
site. Ainsi, un menu aura au plus 3 niveaux de profondeur. Nous éviterons au plus possible de créer des
pages qui ne sont pas en lien avec le menu (mais accessibles par un lien à l’intérieur d’une page de contenu).
• Mettre en place une aide à l’utilisation de module spécifique (cartographie, questionnaire de satisfaction, etc.)
De plus, trop souvent les sites internet sont une succession de page HTML, sans liens entres elles (sauf le menu
général), ce sont des voies sans issues. Nous préconisons à l’essentiel : la force de l’internet et la grosse nouveauté
technique aujourd’hui totalement banalisé est le lien. Nous proposons donc que chaque page de votre site soit en
réalité une page offrant des liens vers d’autres pages de votre site, en guide de lecture (« En savoir plus » ou « Voir
également »).
7/12

8. V1.0 du 14/05/2009
Contenu
CONTENUS OBLIGATOIRES
Les Internautes ayant des habitudes de navigation, nous nous sommes fixés un certain nombre de contenus qui
doivent être présents sur tous nos sites :
• Moteur de recherche (pour site de plus de 20 pages) : il affichera toujours le nombre total de résultats, le
nombre de résultats par page.
• Plan du site, qui fera un lien vers toutes les pages du site.
• Une page crédit (ou mentions légales) précisant le responsable de la publication, les crédits photo, le créateur
du site, l’hébergeur et l’outil de mesure d’audience, ainsi que les dispositions légales (numéro CNIL si
nécessaire).
• Page contact avec un formulaire de contact.
• Une page d’erreur 404 personnalisée qui pointe sur la page d’accueil du site.
CONTENU D’UNE PAGE
Sur toutes les pages de contenu (sauf page d’accueil), devront être présents :
• Un lien vers la page d’accueil
• Un fil d’Ariane
• Le titre de la page
Toutes les images donnant une information à l’internaute (puce, vignette, photo, map, …) devront disposer d’un texte
alternatif n’excédant pas 80 caractères. Les autres devront avoir un ALT vide (conformément aux règles
d’accessibilité en vigueur)
Pour tous les documents en téléchargement, le poids du fichier et l’extension seront précisés.
CONTENUS MULTIMEDIA
Toutes les éléments multimédias (Vidéo, Son, Flash, …) contenant un texte lu à voix haute, seront associés à un
document texte qui retranscrit l’ensemble du texte. De plus, chacun de ces éléments devra disposer d’un texte
alternatif expliquant le contenu de manière claire. L’internaute pourra interrompre la lecture et la reprendre, ou
relancer l’animation.
En fonction de l’extension des éléments multimédias, nous proposerons toujours un lien vers un site permettant de
télécharger un Player (dans la bonne version) pour lire l’élément.
Ces éléments seront appelés en JavaScript afin qu’il n’y ait pas de message d’alerte sur Internet Explorer.
FORMULAIRES
Les formulaires sont des éléments essentiels entre l’internaute et le propriétaire du site. Il convient d’être
particulièrement vigilant à leur réalisation. Nous respectons les règles suivantes :
• Indication des champs obligatoires
• Si un champ obligatoire n’est pas rempli ou mal rempli, le site va préciser à l’internaute quel champ pose
problème pour la validation et pourquoi il y a un problème. Le contrôle de saisie doit être effectué côté client
(en JavaScript) et coté serveur (en PHP).
• Si le formulaire est validé mais que le mail n’a pas été envoyé, on précise à l’internaute qu’il y a eu un
problème.
8/12

9. V1.0 du 14/05/2009
Développement
Les données statistiques aujourd’hui disponibles nous permettent de fixer les critères suivants :
• Le site doit être visible de manière identique sur les navigateurs suivants : IE7 et plus, FF2 et plus, Safari 3 et
plus, Chrome 2 et plus, Opéra 9 et plus. Cela représente 90% des Internautes.
• Toutes les pages du site doivent être visibles sans ascenseur horizontal pour les écrans 1024x768. Cela
représente 97% des Internautes.
• Le poids de la page d’accueil ne doit pas excéder 500ko.
• Limitation du nombre de requête http : (1 seul fichier js, css, regroupement des images de charte)
Les normes
Nous respectons dans nos développements la norme de codage international XHTML 1.0 Transitional et CSS du
W3C. Cela implique notamment :
• Saisir sur toutes les pages du site les éléments : DOCTYPE, LANG, TITLE (différents pour chaque page),
CHARSET, META Description et Keywords.
• Ne pas faire de blocage de l’affichage de la source
• Faire des fichiers séparés pour les fonctions JavaScript et CSS et regrouper ces fichiers en fin de projet.
• Respecter systématiquement les grandes règles Accessiweb.
Commentaires sur le code
Nous avons mis en place une norme de commentaires pour nos codes PhP , directement inspirée de l'annexe B du
« Programmer's Reference Guide » du Zend Framework : http://framework.zend.com/manual/fr/coding-
standard.coding-style.html
Le format de nos commentaires est basé sur la syntaxe PHPDocumentor : http://www.phpdoc.org/
Les exemples suivants constituent le minimum qui doit être présent systématiquement dans tous les fichiers, mais
rien n'interdit d'utiliser des tags additionnels PHPDocumentor.
Un des avantages à utiliser le format PHPDocumentor est qu'on pourra générer de la documentation automatique
lorsqu'on en a besoin.
Nos commentaires sont rédigés en anglais.
Nous vous fournirons notre Charte de convention de codage PhP au début du projet.
Documentation
Nous vous fournirons des documentations pour chaque fonctionnalité mise en place sur votre site. Nos normes de
codages nous permettront de vous fournir des documentations à jour et spécifiques pour les développements réalisés
pour vous.
Gestionnaire de versions
Nous utilisons actuellement GIT en interne pour la gestion de versions.
9/12

10. V1.0 du 14/05/2009
Référencement
Dans le cadre d’une refonte de site, la création de fichier 301 sera réalisée pour conserver le référencement. Il y aura
donc des règles de réécriture.
Mesure d’audience
Nous veillerons à insérer les marqueurs Wysistat, à mettre le bon nom de compte et à vérifier que ce compte existe.
Nous veillerons également à mettre en place le pont automatique de l’arborescence le CMS et /Wysistat.
Contrôle qualité
Le contrôle qualité agit à cette étape au niveau de la qualité du code. Il inclue au minimum les éléments suivants pour
la page d’accueil et une page intérieure :
• Poids de la page
• Nb de requêtes http
• Nombre de fichiers JS, CSS
• Temps moyen de chargement (sur 10 essais depuis notre connexion)
Les réunions
Les réunions internes ou externes doivent respecter les règles suivantes :
• Toute réunion a une durée définie à l’avance, et l’animateur de la réunion s’engage à respecter cet horaire.
• Pour les réunions avec les clients, le chef de projet doit :
o Faire un ordre du jour
o Savoir qui sera présent
o Définir en amont où se tiendra la réunion et si c’est en extérieur s’assurer que le client dispose bien
d’une connexion internet et d’un vidéoprojecteur (projetant une image en 1024px).
• Suite aux réunions, un compte rendu doit être rédigé (2 semaines maximum après la réunion). Pour les
réunions internes, ce compte-rendu peut être un mail, un document.
10/12

11. V1.0 du 14/05/2009
Procédure de publication
Ce processus de publication a plusieurs objectifs :
• Fiabiliser notre processus (éviter les bugs)
• Sécuriser notre processus (éviter les fuites)
Différentes versions d’un site :
• Version interne : version sur notre serveur interne du site. Dès qu’il y a une version de dev, il faut supprimer
les accès externes.
http://local.[nom_client].explid.net
• Version en dev/prédev : version du site sur le serveur d’hébergement, miroir du site publié.
http://dev.[nom_client]. explid.net
• Version de prod/préprod : visible par les internautes et préprod au sens Explid
http://www.[nom_client]. explid.net
Pour nous permettre de nous adapter à plusieurs types et tailles de projets/clients, nous utilisons 2 niveaux :
• Projet de Niveau 1
Avant la publication du site
Accès à la version interne avec authentification (si possible restriction sur IP)
Le développeur a accès au FTP et base de données en futur prod pour publier lui-même
Passage en production sur une URL masquée avec sécurisation par Login/Mot de passe
(accès identique au serveur de dev)
Après la publication
Le développeur peut passer ses développements en prod, selon l’urgence
• Projet de Niveau 2
Création d’un assistant chef de projet dont le rôle est :
D’assurer la cohérence des développements et de la publication
De faire les publications. Faire une publication c’est :
o Vérifier le fonctionnement sur le serveur interne
o Transférer les fichiers sur le serveur de dev et la base de données
o Vérifier le fonctionnement sur le serveur de dev
Dans la mesure du possible, aucune publication ne pourra se faire en son absence. Le chef
de projet doit donc annoncer les congés au plus tôt au client. En cas d’urgence, MM.
Christophe GRAS ou Alexandre Del VECCHIO peuvent le remplacer
Avant la publication du site
Accès à la version interne avec authentification (si possible restriction sur IP)
Seul l’assistant chef de projet a accès au FTP et à la base de données en futur prod pour
publier
Passage en production sur une URL masquée avec sécurisation par Login/Mot de passe
(accès identique au serveur de dev)
Après la publication
Création d’un environnement de dév avec une sécurisation par Login/Mot de passe (accès
identique à la version interne)
L’assistant chef de projet publie les prochains développements sur le serveur de dev et
envoie un mail récapitulatif sur la liste de diffusion en demandant validation
Après validation, l’assistant chef de projet doit publier sur le serveur de prod et envoyer un
mail récapitulatif sur la liste de diffusion. Dans la mesure du possible, il faut laisser le client
faire la publication explid.
En cas d’extrême urgence et si le client demande à supprimer l’étape de publication sur la
version de dev, nous lui demandons de nous envoyer un mail l’expliquant clairement.
11/12

12. V1.0 du 14/05/2009
Afin de sécuriser cette procédure, nous développons des scripts spécifiques et sécurisés :
• Script de transfert d’un site (fichiers, tout ou partie de la base)
• Comparaison de 2 sites sous Explid (fichier/base), pour valider si le processus s’est correctement déroulé.
Sécurité
Nous avons mis en place plusieurs mesures de sécurité et notamment :
• Nous disposons d’un fichier qui liste précisément les éléments suivants :
o Les URLs du projet
o Les personnes ayant travaillé sur le projet (chef de projet, chef de projet adjoint)
• Individualisation des accès : chaque personne doit avoir un login/mot de passe
• Toutes nos entrées DNS sous .idfr.net ou .explid.com sont sécurisées par un htacess (uniquement login/Mot
de passe) et remplacées par des url explid.com
• Tous les mots de passe sont sécurisés en MD5 dans la base.
12/12