V1.0 du 14/05/2009

1/12

Plan Qualité

Version 1.1 :

Le 06/05/2010

V1.0 du 14/05/2009

2/12

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.

V1.0 du 14/05/2009

3/12

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.

V1.0 du 14/05/2009

4/12

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.

V1.0 du 14/05/2009

5/12

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.

V1.0 du 14/05/2009

6/12

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.

V1.0 du 14/05/2009

7/12

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 »).

V1.0 du 14/05/2009

8/12

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.

V1.0 du 14/05/2009

9/12

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.

V1.0 du 14/05/2009

10/12

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.

V1.0 du 14/05/2009

11/12

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.

V1.0 du 14/05/2009

12/12

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.