le guide ultime de la gestion de projet digital

LE GUIDE ULTIME DE LA GESTION DE PROJET DIGITALPRATIQUES & MÉTHODES

Le guide ultime de la gestion de projet digital

2

Avant-propos 3

A propos d’Adimeo 4

Nos métiers 4

Chapitre 1 : Introduction 5Qu’est-ce que la gestion de projet ? 5En quoi la gestion de projet digital / web est-elle si particulière ? 5Les compétences du chef de projet 5

Chapitre 2 : Êtes-vous Agile ou en V ? 6Agilité ou cycle en V ? 6Quand choisir les méthodes agiles ou le modèle en cascade ? 7La planification en cycle en V 7La planification en agilité 8Organisation des équipes 9Organisation & acteurs des équipes en méthodes traditionnelles 9Organisation & acteurs des équipes en méthodes agiles 10

Chapitre 3 : Les grandes étapes de la gestion de projet web classique 11L’avant-projet 12Le cahier des charges 12Le lancement 12La conception et l’UX 13Les développements 15La recette 16La mise en production 17Les versions ultérieures 17La Tierce Maintenance Applicative 17

TABLE DES MATIÈRES

Chapitre 4 : Variantes méthodologiques avec les projets agiles 18

Chapitre 5 : La Qualité d’un projet web 19Qu’est-ce que la qualité d’un projet Web ? 19L’excellent référentiel OPQUAST 19Accessibilité d’un projet Web 20Exploiter des KPI Smarts 21

Chapitre 6 : La stratégie éditoriale ou content marketing 22Définir une stratégie éditoriale dès le début 22Prévoir les ressources suffisantes 22Ecrire pour le Web 22

Chapitre 7 : La prise en compte des contraintes techniques 23Choisir une solution technique 24Sécurité d’un projet Web 24Hébergement 24

Chapitre 8 : Le référencement & campagnes de communication 25

Chapitre 9 : Pour conclure… 26


3

AVANT-PROPOS

La gestion de projet digital est un vaste sujet : les métiers, les solutions, les intervenants sont particulièrement nombreux et variés. La littérature à ce sujet est florissante, chaque auteur apportant sa pierre à l’édifice et approfondissant un sujet nouveau, à la mode et tendance.

Loin de nous l’idée ici d’apporter des idées neuves, de révolutionner les méthodes de la gestion de projet Web ou de décrier telle ou telle approche. Au contraire, il nous a semblé essentiel, dans ce foisonnement de réflexion, d’apporter une vision synthétique, structurée, résumant les grandes approches, les grandes étapes, les méthodes et outils à utiliser.

Prenez ce guide comme un vade-mecum de la gestion de projet digital, qu’il puisse vous accompagner dans vos tribulations digitales et vous apporter de la lumière quand votre veilleuse digitale se met à vaciller.

Et surtout, n’hésitez pas à nous faire vos retours, pour continuer à enrichir ce travail et vous proposer un guide toujours actuel et pertinent.

Bonne lecture !


4

A PROPOS D’ADIMEO

Adimeo est un groupe de transformation digitale qui accompagne les organisations dans leur révolution digitale. De la réflexion stratégique à la réalisation du produit ou du service digital, les équipes d’Adimeo travaillent en équipes pluridisciplinaires pour résoudre des problèmes et inventer des solutions au service de nos clients et des clients de nos clients.

Depuis 15 ans, Adimeo allie des compétences de design, de conseil, d’ingénierie et d’innovation au sein et s’appuie sur des valeurs fortes d’accomplissement, de respect, de sagacité, de liberté et de partage.

NOS MÉTIERS

CONSEIL & STRATÉGIE :Audit, études, positionnement, recommandations stratégiques, AMOA

STUDIO DESIGN UX-UI :Recherches utilisateur, prototypage, tests utilisateur, design d’interaction, design system

PRODUCTION TECHNIQUE :Sites Internet, digital commerce, applications mobiles, applications métier

MARKETING DIGITAL :SEO/SEA/SMO, content & inbound marketing, data & analytics, marketing automation


5

QU’EST-CE QUE LA GESTION DE PROJET ?

Faisons appel à Wikipédia :

« La gestion de projet est une démarche visant à organiser de bout en bout le bon déroulement d’un projet. C’est tout l’opérationnel et le tactique qui fait qu’un projet aboutit dans un triangle représentant l’équilibre qualité-coût-délai (QCD). »

Gérer un projet, c’est assurer sa réussite via une méthode, la réussite du projet étant définie par le respect de l’équilibre qualité – coût – délai défini au préalable.

A cet enjeu d’équilibre s’ajoute la complexité de coordination de très nombreux acteurs, spécialisés dans un domaine de compétence, avec souvent une relation prestataire – client dont les intérêts respectifs doivent être alignés pour la bonne marche du projet.

EN QUOI LA GESTION DE PROJET DIGITAL / WEB EST-ELLE SI PARTICULIÈRE ?

Un projet Web réussi est un projet dont le résultat (le site, le portail, l’application …) a été obtenu dans un cadre périmètre - qualité - coût – délai défini au préalable. La gestion de projet web digitale fait intervenir de nombreux spécialistes : ergonomes,

CHAPITRE 1

INTRODUCTIONux, designer, développeurs front-end, back-end, testeurs, intégrateurs, administrateurs-système, responsables métiers, chefs de produit, …

L’un des grands aspects différenciant d’un projet Web est l’enjeu technologique et humain : l’explosion technologique que nous connaissons depuis la naissance d’Internet complexifie considérablement le travail d’arbitrage, de choix et de mise en oeuvre des projets, tout comme la composante humaine rend la gestion de projet incertaine puisqu’il s’agit de répondre à des attentes d’internautes, d’utilisateurs, de clients, tous différents dans leurs pratiques et leurs usages du média web.

LES COMPÉTENCES DU CHEF DE PROJET

Un chef de projet est le chef d’orchestre du projet, qui connait suffisamment bien toutes les partitions de chacun des intervenants, pour anticiper les étapes à venir, prévenir d’éventuelles difficultés et arbitrer entre plusieurs alternatives lorsque cela est nécessaire.

Il doit donc avoir des compétences managériales, analytiques, techniques, graphiques, ergonomiques, …

Un bon chef de projet est aussi un couteau suisse, capable d’avoir une vision d’ensemble, un esprit analytique, et une grande rigueur dans le suivi des tâches, des intervenants.

On oppose souvent le chef de projet fonctionnel au chef de projet technique. Le premier est issu de la com’, du marketing ; et le second a fait ses armes de développeur lorsqu’il était junior.

Quel est le meilleur profil ? Le chef de projet « non technique » sera parfois déboussolé ou inefficace dans des projets à forte composante technique ou à fort potentiel d’innovation.

Le chef de projet technique manquera parfois de sensibilité UX, n’aura pas toujours tous les enjeux business en main et pourra trop se focaliser sur l’enjeu technique.

En revanche, il est certain qu’un chef de projet technique pourra être un bon chef de projet s’il développe un vrai vernis autour de l’UX, de l’éditorial, de l’analytics, des enjeux business.

Tout comme un chef de projet non technique devra apprendre ce qu’est une CSS, un Webservice ou les contraintes d’un hébergement dans le cloud…


6

AGILITÉ OU CYCLE EN V ?

On oppose souvent la démarche traditionnelle, en cascade ou cycle en V, avec les méthodes agiles, qui sont d’origine plus récentes.

Le modèle en cascade impose une définition préalable complète des besoins, fonctionnalités, attendus et résultats de la future plateforme Web. Le projet est en amont découpé en tâches, avec des jalons précisément identifiés et planifiés. Les étapes de conception sont souvent longues, parfois fastidieuses et imposent une grande rigueur d’exécution. La gestion d’un projet en cascade impose de gérer en complément une « méthode de gestion des risques », pour faire face à tous les imprévus, impondérables et changements qui vont se produire au cours des mois du projet.

Dans les méthodes agiles, l’approche est incrémentale. Itérative elle repose sur le postulat qu’un produit web se construit au fur-et-à mesure selon les retours des utilisateurs et des donneurs d’ordre, et qu’il est impossible, en amont, de faire une estimation réaliste de la charge nécessaire au développement du projet. Aussi, souvent, plutôt que de parler de méthode agile, on parle d’approche agile, d’état d’esprit agile, … Plutôt que de gestion de projet, on parle de gestion de produit.

CHAPITRE 2

ETES-VOUS AGILE OU EN V ?

Les méthodes agiles présentent par ailleurs l’avantage, dans un environnement web en perpétuelle évolution, d’être moins figées et adaptables à l’évolution des pratiques. Il arrive parfois, dans un projet en cascade, de passer de nombreux mois en conception, puis en développement, pour livrer un produit qui est finalement déjà dépassé ou inadapté. C’est le fameux risque de « l’effet tunnel », où le client/donneur d’ordre manque de visibilité sur ce qui lui sera livré bien des mois plus tard.

L’effet tunnel : (à ne pas confondre avec sa définition quantique) C’est la capacité d’un projet Web dans un cycle en cascade à s’écarter des attentes des donneurs d’ordre par manque de reporting, de démonstrations en raison de la longueur des cycles de développement. Le joli dessin ci-dessous illustre parfaitement cette logique :


7

QUAND CHOISIR LES MÉTHODES AGILES OU LE MODÈLE EN CASCADE ?

Parce que le choix de la méthode est déterminant dans la contractualisation, l’organisation des parties prenantes, la construction du planning et des livrables, bref, le déroulement de l’ensemble du projet, le choix de la méthode doit être explicite dès le début du projet et partagé par tous.

Le choix des méthodes agiles / cycle en V repose sur plusieurs considérations :

La maturité des équipes, donneurs d’ordre et porteurs de projet pour prendre en compte tous les préceptes agiles (voir le Manifesto Agile ici) indispensables à la réussite de la méthode ;

L’habitude des équipes à travailler en agilité, avec les bons outils (backlog, burndown chart, vélocité, …) ou leur habitude et leur confiance dans un processus en cascade ;

Le niveau d’incertitude du projet : plus un projet est incertain (fonctionnellement, techniquement, …), plus les méthodes agiles sont nécessaires. Si le projet est une refonte, une évolution bien cadrée et à priori sans complexité ou incertitude, les méthodes en V ont largement fait leurs preuves ;

Le time-to-market : plus les délais sont courts, plus la méthode agile est capable de donner des bons résultats avec l’objectif de mise en ligne du MVP (most valuable product). Cela suppose que les préceptes agiles soient bien intégrés par toutes les parties prenantes. Sinon, c’est l’effet inverse qui risque de se produire ;

Le besoin d’engagement du donneur d’ordre : le périmètre fonctionnel est-il impérativement figé ? Les délais et prix sont-ils verrouillés ? Si les trois variables : prix, délais, fonctionnalités sont figées, l’approche agile est vouée à l’échec (bien que l’expérience démontre que les projets en V avec ces variables figées débordent bien souvent…).

LA PLANIFICATION EN CYCLE EN V

La planification est la grande affaire du cycle en V. On parle au démarrage de « macroplanning »,

qui fixe les jalons de conception, développement, recette, et mise en production. Les étapes de développement peuvent être découpées en plusieurs lots pour permettre de réaliser plusieurs recettes intermédiaires et minimiser ainsi le fameux « effet tunnel ».

Les tâches sont parallélisées ou séquencées selon un diagramme de GANTT. Voici un exemple de planning de GANTT.

Les outils de planification sont nombreux et parfois intégrés aux outils de gestion de projet. Citons : GanttProject, Microsoft Project, Gantter, …

http://agilemanifesto.org/iso/fr/manifesto.html


8

LA PLANIFICATION EN AGILITÉ

En agilité, la planification est toute autre : le délai alloué au projet se découpe en plusieurs sprints, d’une durée équivalente (2 à 4 semaines). A l’initialisation du projet, un backlog produit est défini (liste des attentes fonctionnelles de l’application exprimées sous forme de user stories : « En tant qu’internaute anonyme, je souhaite pouvoir me connecter » ) et est ensuite réparti sur chacun des sprints.

La durée d’une tâche se comptabilise non pas pas en jours/hommes, mais en points de complexité. Un point de complexité est sans unité. Il est évalué par l’équipe de développement, parfois au cours de sessions de « planning poker » (chaque développeur donne son estimation de complexité de la tâche à réaliser). Au fur et à mesure des sprints, le nombre moyen de points de complexité résolus par sprint se stabilise. L’équipe est alors en mesure de définir sa vélocité, c’est-à-dire sa capacité à traiter un volume de points de complexité par sprint.

A l’issue de chaque sprint, une réorientation des priorités et des tâches peut avoir lieu et permet ainsi de réajuster le backlog produit, selon les derniers évènements du projet et les retours des utilisateurs. L’efficacité du dispositif tient ici dans la capacité de réévaluation permanente de la valeur métier de chaque demande fonctionnelle. Cette réévaluation permanente permet d’ajuster les développements au plus près des besoins des clients.


9

Le Comité de Pilotage : Instance décisionnelle du projet qui a pour mission d’orienter le déroulement du projet, et notamment d’en décider les éventuelles évolutions. Il contrôle le bon déroulement du projet, les objectifs, les grandes options, les coûts, et définit les orientations stratégiques. Il est responsable des arbitrages soumis par l’équipe projet et doit pouvoir allouer les moyens nécessaires à celle-ci.

Le Comité Projet : a pour vocation de piloter le moyen et long terme d’une part, les aspects contractuels d’autre part. Il donne une visibilité sur l’avancement du projet et le déroulement des travaux, il identifie les risques et les contournements / ajustements nécessaires, et il prend des décisions sur tout ce qui ne relève pas du comité de pilotage.

Les Réunions fonctionnelles et techniques : Déclenchées en phase de conception, de recette, elles permettent de préciser un besoin, de clarifier une demande, de valider des spécifications, …

ORGANISATION & ACTEURS DES ÉQUIPES EN MÉTHODES TRADITIONNELLES

Dans les méthodes traditionnelles, on parle de comitologie, nom barbare pour dire quelles sont les instances qui se réunissent et avec quels objectifs. Voici les organes possibles :

ORGANISATION DES ÉQUIPES Vous l’aurez compris, méthodes agiles et cycles en V diffèrent également dans leurs principes d’organisation.

Selon les projets, les tailles des équipes, d’autres comités / réunions peuvent voir le jour : comité de suivi technique, comité de suivi, ... Ce qu’il faut retenir, c’est que l’organisation est définie au lancement du projet et se trouve souvent détaillée dans un Plan d’Assurance

Plan Qualité : document assez indigeste qui détaille entre autre l’organisation, les modalités des échanges, les livrables, le suivi des risques, …

Et, en termes d’intervenants, c’est le chef de projet qui assure la majeure partie de la représentativité. Il peut être associé à un Directeur de projets, et éventuellement à un chef de projet technique ou lead technique.


10

Mêlée quotidienne : Réunissant le scrum master (équivalent chef de projet technique), l’équipe de développement et potentiellement le product owner (équivalent chef de projet côté client = chef de projet fonctionnel), cette courte réunion a lieu chaque matin et permet à chacun de répondre aux questions : qu’as-tu fait depuis hier, que prévois-tu de faire aujourd’hui, quelles sont tes difficultés ? Cette réunion permet de faire un point d’avancement, maintenir les objectifs du sprint et désamorcer rapidement toutes les difficultés rencontrées.

Réunion de planification du sprint : Elle est prévue au démarrage de chaque sprint et réunit également toute l’équipe technique et le product owner. Cette réunion permet de définir le but du sprint (fonctionnalité à livrer, architecture à stabiliser, …) et d’y associer toutes les user stories du backlog en les détaillant, les précisant et en les découpant en tâches. Ce travail permet d’obtenir le backlog du sprint, c’est-à-dire la liste des tâches à réaliser au cours du sprint. C’est au cours de cette réunion qu’un planning poker peut être fait pour évaluer la complexité des tâches et donc valider que le nombre de points de complexité prévus dans le sprint correspond à la vélocité de l’équipe.

ORGANISATION & ACTEURS DES ÉQUIPES EN MÉTHODES AGILES

Dans l’approche agile, la réactivité et la prise de décision rapide étant un des facteurs clé de succès, on définit des instances beaucoup plus restreintes et dont les fréquences sont plus rapprochées :

Revue de sprint : C’est l’étape qui permet au product owner et aux autres éventuelles personnes concernées par le projet de prendre connaissance des développements réalisés et de leur fonctionnement. L’équipe projet déroule une démonstration et le product owner et les autres participants donnent leur impression sur le travail réalisé, qui peut se traduire en demandes de changement ou évolutions. Ces demandes-là viennent alimenter le backlog produit.

Rétrospective : C’est peut-être l’une des réunions les plus importantes de la démarche agile mais également la plus difficile à mener de manière efficace et complète : l’idée sous-jacente est celle de l’amélioration continue : quels ont été les problèmes de fonctionnement rencontrés au sein de l’équipe, et comment faire pour les résoudre et améliorer ainsi le déroulement du projet dans son ensemble ? On peut ainsi constituer un plan d’action pour le sprint suivant, listant toutes les démarches et actions à mener pour résorber les difficultés rencontrées.

ORGANISATION DES ÉQUIPES Vous l’aurez compris, méthodes agiles et cycles en V diffèrent également dans leurs principes d’organisation.


11

CHAPITRE 3

LES GRANDES ETAPES DE LA GESTION DE PROJET WEB CLASSIQUE

L’avant-projet

Le cahier des charges

La conception et l’UX La recette

Les versions ultérieures

Le lancement Les développements La mise en production

La Tierce Maintenance Applicative

01 02 03 04 05 06 07 08 09


12

01. L’AVANT-PROJET

L’avant-projet se caractérise souvent par une intense phase d’analyse stratégique : quels sont les besoins, quelles sont les contraintes, qui sont vos utilisateurs, qui sont vos concurrents, quelle est votre valeur ajoutée, … L’avant-projet sert généralement à définir les grandes orientations stratégiques du projet et poser la vision. Dès que le projet devient un peu gros, on peut solliciter ce que l’on appelle une AMOA (Assistance à Maîtrise d’Ouvrage), qui va se charger de mener les entretiens avec les équipes, les publics, organiser les focus group de collecte d’information, auditer l’existant, d’un point de vue fonctionnel, technique, ergonomique (…).

Lors de cet avant-projet, selon la criticité de l’expérience utilisateur, il est possible de mener des enquêtes, tests utilisateurs, études ethnographiques. L’UX peut créer des personas, des « experience map ». Toutes ces démarches peuvent également se retrouver lors des étapes de conception.

L’objectif de l’avant-projet est avant tout de définir un cadre stratégique, qui répond aux questions suivantes :

Quel projet ?

Pourquoi ce projet ?

Comment mener ce projet ? (avec quelles équipes, prestataires, budget)

Dans quel délai ?

Quels sont les indicateurs de performance à suivre ?

02. LE CAHIER DES CHARGES

Nous ne nous attarderons pas longtemps ici sur la question du cahier des charges. De très nombreuses publications y font déjà référence, et nous avons nous-même produit un modèle type de cahier des charges, téléchargeable dans le kit des modèles de document.

Rappelons juste qu’un cahier des charges est essentiel. Il permet de choisir les bons prestataires (si vous externalisez), il fixe un cadre et partage avec l’ensemble des acteurs la vision commune du projet.

03. LE LANCEMENT

L’étape de lancement, relativement courte, permet de mettre tous les acteurs du projet autour d’une table pour préciser :

Qui fait quoi ;

Les instances (comitologie, réunions) et leur périodicité ainsi que les prochaines réunions ;

Le macro-planning ;

Les documents et données en entrée (existant, études préalables, code source, API, …).

https://ressources.adimeo.com/kit-mod�le-de-document-gestion-digitale



13

04. LA CONCEPTION ET L’UX

La phase de conception est la plus critique du projet : elle doit être menée avec une grande rigueur et une grande exhaustivité, sans quoi les oublis et les manques devront être traités en phase de recette, avec une crispation parfois importante entre les différents intervenants. Il vaut mieux prendre un peu de retard à cette étape pour définir l’intégralité du projet, sinon, ce temps gagné ici sera perdu et multiplié par 2 ou 3 (en étant optimiste) lors des phases de livraison.

Le livrable principal de cette étape est constitué par les Spécifications Fonctionnelles et Techniques, qui détaillent, fonctionnalité par fonctionnalité, écran par écran, processus par processus, l’ensemble des attendus. Ce document peut être découpé en plusieurs :

Spécifications Générales, Spécifications fonctionnelles détaillées, Spécifications techniques, … Là encore, tout dépend du niveau de formalisme attendu et de la taille du projet. L’essentiel est que les différents intervenants soient d’accord en lancement de projet sur les livrables attendus.

En amont, la phase de conception est l’étape privilégiée de l’UX. Selon les projets, les moyens, beaucoup de démarches peuvent être mises en oeuvre. Si vous souhaitez découvrir les meilleures méthodes de design de l’expérience utilisateur, nous avons animé un webinar sur le sujet ! Jetez-y un coup d’oeil.

https://ressources.adimeo.com/webinar-meilleures-methodes-design-experience-utilisateur

https://ressources.adimeo.com/webinar-meilleures-methodes-design-experience-utilisateur


14

Sinon, voici en bref la liste (non exhaustive) des démarches UX possibles :

Etudes et recherches utilisateur : pour comprendre les utilisateurs, leurs attentes, leurs freins, leurs usages. On parle aussi de design thinking ou d’idéation.

Etudes ethnographiques : permet d’observer et d’interviewer des panels d’utilisateurs en situation d’usage. Cette méthode peut utiliser des techniques dites « fly on the wall », « shadowing » ;

Personas : représenter les motivations, les freins et les usages de vos différents utilisateurs cibles ;

Cartographie de l’expérience utilisateur : représenter tous les contextes d’usage au cours d’un parcours utilisateur ;

Tests utilisateur

Audits ergonomiques : utiliser l’expertise d’un ergonome, de certains référentiels (comme Bastien et Scapin) pour identifier les grandes erreurs ergonomiques d’une application existante ;

Eye-tracking, cartes de chaleur : permet de visualiser sur une application existante là où les yeux de l’utilisateur se portent, là où ils cliquent, scrollent, …

Focus group & enquêtes (en ligne ou pas).

Conception d’interfaces

Benchmarks d’applications concurrentes ou similaires ;

User-flow : décrit l’enchaînement des étapes et des écrans de manière synthétique ;

Maquettage et prototypage d’interfaces (dynamiques ou non) : on parle de wireframes, zonings fonctionnels, mockups,… qui peuvent se démarrer avec une méthode intitulée « six-to-one » ;

Tris de carte : indispensable pour aider à la définition de l’architecture de l’information. Comment organiser les contenus et les fonctionnalités ? Avec quel wording et quelle logique de regroupement. C’est une démarche participative principalement utilisée pour définir le menu principal ;

Charte ergonomique, couplée éventuellement à un style guide définissant tous les éléments génériques de la charte ;

Design graphique : réaliser « l’habillage graphique » des prototypes. Ici attention, le Directeur Artistique n’a pas vocation à colorier les prototypes : il doit pouvoir les challenger, imaginer d’autres design d’interaction et proposer des alternatives ;

Tests utilisateur : qui peuvent être menés sur les prototypes, sur les maquettes animées ou une fois l’application développée ;

Tests A/B : pour identifier quelle est la version d’une page / d’un bouton / d’un contenu (…) qui « transforme » le mieux.

Dans un prochain document, nous vous proposerons en détail une analyse de toutes ces méthodes.


15

05. LES DÉVELOPPEMENTS

Les développements peuvent démarrer une fois que l’ensemble des processus fonctionnels, des échanges techniques des interfaces, l’UX et le graphisme ont été définis.

Un planning détaillé des différentes tâches de développement est réalisé (sous un format de type GANTT), identifiant les tâches pouvant être menées en parallèle (et donc confiées à plusieurs développeurs), de celles qui sont séquentielles (une tâche donnée ne pouvant être réalisée avant la réalisation d’une autre). Ce planning détaillé permet de donner le chemin critique vers la livraison de l’ensemble du projet. Pour éviter les effets tunnel, différents lots de développement peuvent être définis, découpant le projet en plus petites étapes et permettant de lancer des étapes de recette intermédiaires.

Dès que vous le pouvez, adoptez cette démarche de découpage. En effet, les équipes « clientes » sont peu actives pendant la phase de développement, et les solliciter rapidement pour démarrer la recette et éventuellement de la saisie de contenu permet de raccourcir les étapes finales de livraison et raccourci infine les délais du projet.

Pendant cette phase de développement, le chef de projet ne doit pas perdre le contact avec l’équipe client : à minima un point hebdomadaire doit être tenu, pour tenir au courant de l’avancement, des difficultés rencontrées, des éventuelles questions de l’équipe de développement, ou tout simplement pour préparer les étapes de recette, de reprise d’un existant ou d’alimentation en contenus.

L’équipe de développement doit de son côté, adopter des démarches de développement cadrées, normées, avec, à minima, des logiques de tests unitaires.

Enfin, toujours, prévoyez en tant que chef de projet, une étape de « recette interne ». Ne livrez pas à votre client l’application directement sortie des mains des développeurs. Faites une revue qualité sur l’ensemble des fonctionnalités, en mettant en place si besoin un cahier de recette (selon votre méthode de tests retenue) et déroulez tous les scénarii de l’application. L’objectif de cette recette interne est de livrer au client l’application la plus exempte d’anomalies possible, et que ce dernier se concentre éventuellement sur des détails.

A l’issue des développements (ou pour la livraison du lot concerné), selon l’organisation projet définie en phase de lancement, vous mettez à disposition de votre client :

L’application prête à être testée (dans un environnement de recette) ;

Avec des données et des jeux de test (comptes utilisateurs fictifs, contenus repris, variables réelles, …) ;

Avec un plan de test et un cahier de recette (si c’est au chef de projet que revient cette charge – bien qu’il soit souvent préférable que ce soit le client ou l’AMOA qui s’en charge).w


16

06. LA RECETTE

La recette, la « mal-aimée » des projets… Et pourtant ! C’est dans cette étape que la plus grande rigueur est de mise ! Réussir la recette d’un projet Web, c’est mettre en oeuvre correctement toutes les étapes suivantes :

La définition d’une stratégie de recette : qui recette quoi ? dans quel délai ? Quelles sont les normes à recetter (accessibilité, performance, navigateurs, …) ;

La rédaction d’un plan de tests : quelles exigences fonctionnelles doivent être testées, quelle est la criticité de ces exigences, quels types de tests à réaliser, quels besoins techniques et fonctionnels à vérifier ?

Le cahier de tests : décrit en détail tous les tests à mener, leur niveau de maille, avec des scénarios, des jeux d’essais, les pré-requis et des pas de tests ;

Le déroulement effectif des tests, qu’il faut voir comme une série d’allers-retours entre les testeurs et les développeurs : chaque anomalie, une fois corrigée, doit être à nouveau testée, pour en valider le bon fonctionnement et alors clôturée. Et ce n’est que lorsque l’ensemble des anomalies évaluées comme « prioritaires avant mise en ligne » que la mise en ligne peut effectivement être déclenchée.

Comment évaluer les délais d’une recette ?

L’une des principales causes de retard d’un projet web réside dans la prolongation des délais de recette, avec des anomalies qui sont déclarées au fur et à mesure, des régressions, et des délais de correction qui s’éternisent. Pour contrôler cette incertitude, une seule solution : le suivi de recette. Cette dernière doit vous permettre de matérialiser :

Le nombre de tests restant à mener ;

Le nombre de cas de tests en anomalie.

A partir de là, vous pourrez extrapoler le temps restant de recette sur la base du temps déjà passé en recette et du nombre d’anomalies clôturées.

Nous vous proposons également dans ce kit de documents de gestion de projet un modèle de cahier de recette.

Pour bien mener une recette, il faut également être bien outillé :

Utilisez un outil de suivi d’anomalies ou bugtracker : Mantis, Redmine, Jira, … quantité d’outils existent sur le marché. Adoptez également une démarche rigoureuse de

N’attendez pas la mise en ligne pour vous rendre compte que votre site crashe avec plus de 100 utilisateurs connectés. Les tests de performance impliquent de définir des exigences minimales, des scénarios.

qualification d’une anomalie : quel est son niveau de criticité, ajoutez des copies d’écrans, quel(s) navigateur(s) sont concernés, … Cela évite les allersretours de demandes de précisions.

Utilisez des émulateurs de navigateur. Difficile en effet d’avoir sur un même poste différentes versions d’Internet Explorer, Firefox et Safari ! Ces émulateurs peuvent aussi tester les comportements en responsive selon les résolutions les plus courantes.

Une recette, n’oubliez pas, doit également servir à valider :

La performance d’une application. N’attendez pas la mise en ligne pour vous rendre compte que votre site crashe avec plus de 100 utilisateurs connectés. Les tests de performance impliquent de définir des exigences minimales, des scénarios. Les résultats des tests de performance permettent d’identifier les goulots d’étranglement et l’équipe de développement / infogérance doit alors oeuvrer pour optimiser ces performances.

La sécurité d’une application : tests en boîte noire, blanche, grise, tests d’intrusion, audit de code, … Plusieurs variantes existent, mais en ces temps d’accroissement de la cybercriminalité, le vol ou la perte de données peut être dramatique pour votre business.

L’accessibilité : vous pouvez l’intégrer dans votre recette fonctionnelle, tout comme en confier la charge à un expert en accessibilité.




17

07. LA MISE EN PRODUCTION

La mise en production ou mise en ligne est l’occasion certes de déboucher le champagne, et doit être préparée avec la plus grande vigilance ! Un retro-planning presque horaire doit être défini et prend en compte :

La migration des DNS et les délais de propagation ;

Les redirections 301 en cas de refonte et le suivi des erreurs 404 post mise en ligne ;

Le contrôle des statistiques de visite et de référencement ;

Le suivi des performances du site ;

Et bien évidemment toutes les démarches de communication entourant ce lancement !

08. LES VERSIONS ULTÉRIEURES

La démarche réussie de gestion d’un projet digital s’inspire des démarches de « test and learn » et de logique « bêta ». Si vous avez pour ambition au démarrage de votre projet de sortir un site qui soit déjà dans sa version définitive, ce n’est pas la bonne approche ! En effet, entre la date de démarrage et la date effective de mise en ligne, beaucoup de choses se seront passées. Vous avez normalement dû choisir de renoncer à certaines

fonctionnalités et vous allez vous rendre compte à l’usage que certaines fonctionnalités, interfaces (…) ne correspondent pas aux besoins des utilisateurs.

Et surtout, vous allez mettre en place les outils pour identifier ce qui marche et ce qui ne marche pas ! Tests A/B, audits statistiques, plan de marquage, tests utilisateurs, enquêtes, …

Aussi, votre première mise en ligne devra toujours être suivie d’autres mises en ligne, plus ou moins conséquentes, plus ou moins rapprochées.

Selon votre rythme d’évolutions et de versions, il sera certainement nécessaire de mettre en place des démarches d’intégration continue (ou plutôt de déploiement continu) ; c’està- dire des outils, des méthodes et des pratiques qui facilitent, automatisent et améliorent la qualité des étapes de tests, mise en production et de contrôle. Là encore, le sujet de l’intégration continue est vaste, nous vous proposerons aussi d’autres lectures à ce sujet prochainement.

La démarche réussie de gestion d’un projet digital s’inspire des démarches de « test and learn » et de logique « bêta ».

09. LA TIERCE MAINTENANCE APPLICATIVE

Avez-vous défini également les processus de TMA (Tierce Maintenance Applicative) ? C’està- dire la manière dont les équipes techniques interviennent pour « maintenir en conditions opérationnelles » votre application Web ? Ici, on parle souvent de :

TMA corrective, qui peut se décomposer en TMA préventive, adaptative ;

TMA évolutive.

Si vous êtes dans une démarche totalement agile et que vous avez intégré les principes du « test and learn » décrits dans le paragraphe précédent, ces différentes logiques d’intervention ne vous concernent pas nécessairement.

Si vous êtes dans une démarche plus « traditionnelle », il faut avoir anticipé et contractualisé cette TMA avant la mise en ligne, en ayant notamment précisé le cadre et la durée de la garantie (si vous avez fait appel à un prestataire externe).

La TMA corrective doit notamment préciser les délais d’intervention et de correction en cas d’anomalie. Ces délais varient de 2h à plusieurs jours selon la gravité de l’anomalie.

Et n’oubliez pas ! Prévoyez toujours un cadre de réversibilité ; c’est-à-dire l’engagement du prestataire à accompagner vos équipes ou tout autre intervenant si vous avez décidé de vous séparer de lui.


18

Il est certain que, dans une méthode agile, vous n’aurez pas ce cycle de réalisation :

conception, développement, recette. Mais plutôt chacune de ces étapes est condensée dans un sprint. En effet :

La définition du sprint backlog permet de répondre à toutes les questions fonctionnelles relatives aux développements prévus dans le sprint et en précise les détails ;

La revue de sprint constitue une étape de recette / validation ;

Les développements sont réalisés au cours des 2 à 4 semaines que dure le sprint.

Néanmoins, il faut savoir qu’il est impossible de mener au cours d’un même sprint la conception UX d’un projet et son développement. Aussi, plusieurs alternatives existent :

CHAPITRE 4

VARIANTES METHODOLOGIQUES AVEC LES PROJETS AGILES

On découpe les sprints UX des sprints de développement. Chaque sprint UX doit précéder d’au moins 2 sprints les sprints de développement. Par exemple, dans un projet Ebusiness, vous définissez les principes utilisateurs du tunnel de commande deux sprints avant le développement technique effectif du tunnel de commande.

La démarche UX est considérée comme une release à proprement parler. Toutes les étapes de recherche utilisateur, définition des parcours, wireframing (…) est une release en tant que telle et est planifiée quelques semaines / mois avant le démarrage effectif du projet en développement.

Par ailleurs, la démarche agile impose également la présence / disponibilité de l’UX et du DA tout au long du projet : ces derniers doivent pouvoir interagir en direct avec les développeurs, préciser les interactions, affiner des choix graphiques, designer de nouvelles interfaces non prévues mais rendues nécessaires, …

Dans un projet agile, la difficulté réside souvent dans la coordination entre les travaux UX et les travaux de développement, qui ne se déroulent pas selon la même temporalité : la recherche de la meilleure expérience utilisateur nécessite du temps, parfois incompatible avec les exigences agiles de développement technique. Aussi, il est essentiel d’anticiper ces besoins UX, de correctement les calibrer et de prévoir leur impact sur les sprints de développement.

Par ailleurs, dans un projet agile, plusieurs sprints peuvent constituer une release, et chaque release fait l’objet d’une mise en ligne. Il est utile, dans une release, de prévoir un sprint 0, qui permet d’étoffer le backlog, l’organisation des équipes, les pré-requis techniques, les validations graphiques (…), tout comme prévoir un sprint final, destiné à la recette globale de la release et permet de corriger / améliorer tous les points bloquants pour la mise en ligne.


19

QU’EST-CE QUE LA QUALITÉ D’UN PROJET WEB ?

Qu’est-ce qui rend votre projet Web plus réussi qu’un autre ? Quantité de facteurs entrent en ligne de compte. Voici une petite liste d’indicateurs qui vont caractériser la qualité de votre projet, certains étant plus subjectifs que d’autres :

L’esthétique : c’est le principal critère pour tout internaute à qui vous poserez la question. Mais attention ici, ce critère est totalement subjectif et dépend de la personne à qui vous vous adressez et de ses pratiques. Pour un professionnel du Web, l’esthétisme n’est pas à confondre avec l’ergonomie. Pendant des années, le site d’Amazon était particulièrement peu esthétique, mais avec une ergonomie exceptionnelle et un taux de transformation très performant. La qualité graphique d’un projet Web est très largement à rapprocher des tendances et des modes. Ces dernières années, on a pu parler de flat design / material design, d’immersivité, de typographies imposantes, de design d’interaction avec du parallaxe ou d’autres effets interactifs, …

L’ergonomie : c’est certainement LE critère de réussite d’un projet Web. Le site estil simple, efficace, pratique, intelligible, … ? On a beaucoup parlé dans ce document d’UX, de recherche utilisateur, d’amélioration

CHAPITRE 5

LA QUALITE D’UN PROJET WEB

de l’expérience. Un projet Web réussi, c’est essentiellement parce qu’on a pris en compte les besoins utilisateur. Et de là découlent la qualité esthétique, la qualité fonctionnelle, les performances, le taux de transformation, …

Le référencement : Si votre site est esthétique et ergonomique, mais qu’il est invisible des moteurs de recherche, tout le travail réalisé ne sert à rien ! Un site réussi est évidemment un site bien référencé, tant sur son url de référence que sur l’ensemble des mots-clés que les utilisateurs tapent pour accéder à une information véhiculée par le site. Un site réussi est bien un site qui est en tête des moteurs de recherche sur une longue traîne de mots-clés apportant du trafic qualifié.

L’éditorial : c’est le contenu qui fait rester et revenir vos internautes sur votre site Internet. Ici encore, si le contenu est plat, inintéressant, mal organisé, mal rédigé, peu attractif, …, vous perdez vos internautes qui ne reviendront plus. Aussi, un site réussi, c’est évidemment un site de grande qualité éditoriale, avec une ligne explicite, respectée dans tous les contenus, disposant d’une grande variété de contenus multimédias et avec des angles et des

approches uniques. La réussite d’un site passe par la qualité de sa stratégie éditoriale.

Les performances : Amazon déclarait gagner plusieurs milliers de commandes supplémentaires lorsque son site était plus rapide de quelques dixièmes de secondes. Sans aller jusqu’à ces extrêmes, les statistiques de fréquentation, de taux de rebond, de transformation (…) sont directement impactées par la vitesse de chargement d’un site Web. Aussi, toute lenteur (ressentie ou réelle) impacte défavorablement la qualité de votre site.

Accès en mobilité : En 2016, le volume de consultation sur appareil mobile a dépassé celui des appareils desktop. Il n’est plus possible de faire l’impasse sur les accès mobiles, qu’il s’agisse de réaliser un site Responsive ou un site dédié. La qualité d’un site mobile se mesure dans l’efficacité des accès aux contenus, les alternatives de navigation à la souris, les fonctions de saisie des formulaires, …

L’EXCELLENT RÉFÉRENTIEL OPQUAST

Il existe aujourd’hui un excellent outil pour mesurer objectivement la qualité de votre projet Web : le référentiel OPQUAST. Mis à jour régulièrement, ce référentiel dispose de grilles d’analyses complètes et d’outils d’analyse en ligne. Ce référentiel doit être la bible du chef de projet !

A tel point que des certifications Opquast ont vu le jour récemment. Si votre chef de projet est certifié Opquast, c’est un bon indicateur de sa compétence.

Pendant des années, le site d’Amazon était particulièrement peu esthétique, mais avec une ergonomie exceptionnelle et un taux de transformation très performant.


20

ACCESSIBILITÉ D’UN PROJET WEB

L’accessibilité du Web est définie par la WAIW3C 3 comme l’une des composantes de l’accessibilité numérique :

Nous aurions aussi pu ranger l’accessibilité un critère de qualité Web, tant les exigences d’accessibilité se confondent parfois avec les critères de qualité d’un site Web. Aussi, s’assurer de l’accessibilité d’un projet Web, au-delà de le rendre visible pour près de 15% de la population, est également un gage de performance, puisque les critères d’accessibilité concourent à améliorer le référencement, les performances, l’éditorial et l’ergonomie.

Pour contrôler l’accessibilité d’un projet Web, là encore, plusieurs référentiels existent :

Le WAI et le référentiel WCAG : Web Accessibility Initiative ;

Le RGAA : Référentiel Général d’Accessibilité des Administration ;

AccessiWeb : référentiel un peu en perte de vitesse.

Ces référentiels se décomposent 3 niveaux d’exigences. Pour le RGAA, il s’agit des labels A, AA et AAA. Le label A étant le moins contraignant et sans doute le minimum vital pour tout site de qualité.

Seul manque à ce jour : l’accessibilité en environnement mobile n’est pas aujourd’hui établie. Les professionnels disposent de bonnes pratiques, mais qui ne sont pas formalisées dans un référentiel reconnu.

L’accessibilité du web signifie que les personnes handicapées peuvent l’utiliser. Plus spécifiquement, elle signifie que ces gens peuvent percevoir, comprendre, naviguer, interagir avec le web, et y contribuer. L’accessibilité du Web bénéficie également à d’autres, notamment les personnes âgées ayant des capacités diminuées dues au vieillissement.


21

EXPLOITER DES KPI SMARTS

La qualité d’un projet Web ne saurait non plus être évaluée sans la définition d’indicateurs de performance. Si la démarche bêta est bien mise en oeuvre, il faut évidemment disposer d’indicateurs objectifs pour mesurer l’amélioration des performances du projet et mener les adaptations nécessaires pour corriger ou améliorer l’existant. Dans le meilleur des mondes, ces KPI sont définis dès le lancement du projet et sont ajustés au fur-et-à-mesure de la vie du projet. Il existe un outil pour bien construire ces KPI, les KPI SMART :

Ces indicateurs vont très largement s’appuyer sur les données statistiques de votre site, à partir d’un outil tel que Google Analytics, Piwik (plus respectueux de la CNIL), ou son alternative payante : Xiti. Vous pourrez déployer simplement un tag statistique sur vos pages ou créer un plan de marquage plus complet, vous permettant d’obtenir des informations plus précises sur les parcours utilisateur, les indicateurs de transformation (…).


22

DÉFINIR UNE STRATÉGIE ÉDITORIALE DÈS LE DÉBUT

On l’a vu, la qualité de votre site Web est indissociable de la qualité intrinsèque de vos contenus. Sans contenu efficace, bien pensé, bien organisé, bien structuré, bien écrit, vous allez vite perdre et décevoir vos internautes. Aussi, la définition d’une stratégie éditoriale cohérente est concomitante de l’étape de conception UX. Une stratégie éditoriale, c’est :

La définition des objectifs de votre site et de votre message ;

L’identification précise de vos cibles et de leurs attentes ;

La définition de la matrice de vos contenus (quel contenu ? quel format ? à quel moment ?)

Cette stratégie de contenu s’accompagne d’une charte éditoriale qui précise les méthodes et les manières de rédiger (ton, style, formats des contenus, interdits et recommandations) ainsi que d’un planning éditorial précis pour rythmer les publications.

CHAPITRE 6

LA STRATEGIE EDITORIALE OU CONTENT MARKETING

PRÉVOIR LES RESSOURCES SUFFISANTES

Une stratégie de contenu efficace et pérenne s’appuie sur des contributions régulières, actualisées et de qualité. Ce n’est pas un travail qu’il est possible de confier à un stagiaire.

Aussi, prévoyez les ressources suffisantes, notamment en phase de lancement du projet, pour la reprise de l’existant, qui est toujours plus longue, complexe et fastidieuse qu’initialement envisagé. A titre d’exemple, pour une reprise « simple », sans réécriture, ni travail sur les visuels, il faut compter 30 contenus / jours. Cette moyenne dépend évidemment de la complexité de vos contenus, du CMS utilisé.

ECRIRE POUR LE WEB

Enfin, la qualité éditoriale se mesure également à la qualité de l’écriture du contenu. Il faut garder en tête que l’on écrit différemment sur le Web des autres supports : l’internaute est par nature zappeur, multitâches et ne lit qu’un mot sur 5 en se concentrant sur les titres et les mises en exergue. Il faut donc veiller à écrire de manière simple, concise, en évitant les tournures complexes et négatives et en usant de nombreux contenus multimédias et de liens internes.

Nous vous invitons à consulter la publication suivante : les 10 commandements d’une stratégie éditoriale de qualité, qui vous donne les clés d’un contenu efficace.

Vous pouvez également télécharger notre kit de modèles de documents pour optimiser votre rédaction de contenus Web.

https://adimeo.com/publication/les-10-commandements-dune-strategie-editoriale-de-qualite

https://adimeo.com/publication/les-10-commandements-dune-strategie-editoriale-de-qualite

https://ressources.adimeo.com/kit-mod%C3%A8le-de-document-gestion-digitale




23

Un projet digital est intiment lié à la technique. Selon le profil du chef de projet et les spécificités du projet, l’environnement technique est un élément plus ou moins critique.

Les contraintes techniques d’un projet peuvent être liées à :

Un existant ou un écosystème technique dans lequel il faut s’intégrer : les données du projet web doivent s’appuyer sur un système d’information particulier, sur un logiciel externe ; le projet doit pouvoir communiquer des données vers d’autres solutions ; le projet doit s’interfacer avec des composants techniques hétérogènes ; l’infrastructure d’hébergement est particulière ; …

Des exigences particulières : de sécurité, de confidentialité, de performance, … qui imposent des normes techniques spécifiques et des contrôles de mise en oeuvre.

Dans les deux cas, la spécification exhaustive de l’ensemble de ces contraintes doit être menée en amont du projet, afin d’éviter toute mauvaise surprise qui peut aller jusqu’à remettre en cause l’ensemble du projet.

CHAPITRE 7

LA PRISE EN COMPTE DES CONTRAINTES TECHNIQUES


24

HÉBERGEMENT

L’hébergement est également important dans la gestion de votre projet digital : à qui allezvous confier l’hébergement de votre projet ? Allez-vous basculer dans le cloud ? Un hébergement mutualisé suffit-il ? Les bonnes questions à se poser sont les suivantes :

Quel est le niveau d’indisponibilité que vous pouvez supporter pour votre site Internet ? (jamais, quelques heures par mois, quelques heures par an) ?

En cas de crash important, quel est le niveau de réactivité attendu ?

Quels sont les engagements de sécurité minimaux ?

De quels services d’infogérance avez-vous besoin ?

Votre architecture technique est-elle complexe et nécessite-t-elle un dimensionnement et une organisation particulière ?

Avez-vous une grande variabilité dans les volumes de visites et de transactions ?

Avez-vous besoin de mettre en place des principes d’intégration continue / devops ?

En fonction de ces réponses, vous pourrez soit vous adresser à un hébergeur qui fournit un hébergement mutualisé / dédié sans infogérance, soit vous ferez appel à des prestations d’infogérance complémentaire, ou vous pourrez basculer dans le merveilleux univers du cloud.

CHOISIR UNE SOLUTION TECHNIQUE

Au-delà de ces contraintes techniques, il est nécessaire, au démarrage du projet, de choisir LA solution technique : faut-il un CMS, une solution d’Ecommerce, un portail, des développements spécifiques avec un frameworks ? Comment identifier la bonne solution dans un univers technique que l’on ne maîtrise pas toujours ? Il n’existe en effet pas de meilleure solution, mais des bonnes solutions adaptées à votre projet et à votre contexte. Les grands critères de choix suivants sont à prendre en compte :

La réponse de la solution à votre périmètre fonctionnel ;

La qualité intrinsèque de la solution (open source, propriétaire, pérennité, exemples d’implémentation similaires, …)

La capacité évolutive de la solution ;

Les réponses de la solution face à vos contraintes techniques ;

Nous avons également rédigé un document intéressant que vous pouvez lire sur ce choix éminemment complexe : « Quelle solution pour quel projet Web » ?

Nous avons également réalisé quelques analyses sur le choix des solutions d’Ecommerce et des usines à site.

SÉCURITÉ D’UN PROJET WEB

La sécurité d’un projet web n’est pas à prendre à la légère : tous les jours, des petits et des grands sites Web se font hacker avec parfois des conséquences désastreuses. Aussi, il faut être vigilant sur les points suivants :

Les développeurs sont-ils formés aux risques de sécurité et appliquent-ils les standards ? Le plus connu étant le standard de l’OWASP, qui référence les failles les plus critiques, mais chaque solution technique (de qualité) dispose également d’un suivi rigoureux des failles constatées et des patchs de sécurité associés.

Les développements font-ils l’objet d’une revue de code intégrant des contrôles de sécurité ? Utilisez-vous des outils automatiques d’analyse de code ?

La solution mise en oeuvre dispose-t-elle d’une procédure d’application des patchs de sécurité fournis par l’éditeur ou la communauté ? Ces patchs sont-ils appliqués avec une réactivité suffisante ?

Avez-vous mené des tests de sécurité avant la mise en ligne ? En réalisez-vous régulièrement ?

https://ressources.adimeo.com/quelle-solution-pour-quel-projet-web

https://ressources.adimeo.com/quelle-solution-pour-quel-projet-web

https://ressources.adimeo.com/3-outils-et-m�thodes-pour-faire-le-bon-choix-de-votre-solution-ecommerce

https://ressources.adimeo.com/quelles-solutions-et-r�ponses-pour-votre-projet-dusine-�-site-�-sites

https://owasp.org/www-project-proactive-controls/


25

Le référencement de votre projet Web est un projet à part entière. Votre projet de référencement doit disposer d’un budget dédié (souvent important), d’un planning en relation directe avec le planning de réalisation du site Internet. Quand on parle de référencement, il faut distinguer les grandes alternatives :

Le référencement technique : toutes les démarches d’optimisation technique des pages qui feront que vos contenus seront lisibles et indexables par les moteurs de recherche. C’est le minimum vital que vous devez attendre d’un projet Web. Il existe également des recommandations fortes d’optimisation technique, comme l’utilisation d’un certificat https, l’optimisation mobile, l’utilisation de balises Schema.org, …

Le référencement naturel : tout le travail relatif à la structure globale du site, au contenu éditorial, aux mots-clés et au netlinking. Ce référencement naturel est le plus complexe mais également celui avec le retour sur investissement le plus intéressant ;

CHAPITRE 8

LE REFERENCEMENT & CAMPAGNES DE COMMUNICATION

Le référencement payant : tous les dispositifs où vous allez dépenser de l’argent selon le nombre de personnes qui vont cliquer sur vos annonces. On parle de SEM, de retargeting.

Sur ces sujets, le web regorge de littérature et nous n’avons pas vocation ici à vous proposer des éléments d’approfondissement. Les points de vigilance doivent être les suivants :

Le référencement est un sujet en perpétuelle évolution. Les algorithmes des moteurs de recherche changent tous les jours et savoir identifier ce qui marche de ce qui n’a pas d’impact est complexe ;

De très nombreux acteurs proposant des prestations de référencement existent. Attention, selon nous, il y a beaucoup de « charlatans » : dans le choix de votre agence de référencement, prenez des références auprès de leurs clients existants, demandez des KPI de réussite sur des projets précédemment menés et exigez un suivi précis du positionnement.


26

La réussite de votre projet digital passe par la maîtrise et l’anticipation de chacune des étapes décrites dans ce document. S’il ne fallait retenir qu’une chose pour que votre projet digital se passe bien, c’est le mot ADAPTABILITE. Il est impossible de tout prévoir, tant dans l’organisation interne du projet que dans les évènements extérieurs qui peuvent survenir.

C’est la vocation d’un projet digital que d’être bousculé par des évènements internes et externes : une innovation technologique qui bouscule votre business model, des utilisateurs qui ne répondent pas du tout comme on s’y attendait, des contraintes techniques plus fortes qu’envisagées, un facteur humain qui y met du sien… Tous les intervenants doivent faire preuve de souplesse, ce qui, bien évidemment ne doit pas remettre en question l’engagement total, la proactivité et la diligence de chacun pour répondre aux attentes de tous.

CHAPITRE 9

POUR CONCLURE…

le guide ultime de la gestion de projet digital

Documents