Un projet Web réussi n’est pas celui qui évite tous les problèmes, c’est celui qui les anticipe. Gouvernance floue, choix techniques inadaptés, sous-estimation des délais, etc., ces risques surgissent sur la plupart des projets, mais ils ne sont pas inévitables.
Cheffe de projet digitale en agence depuis 15 ans et Directrice de projet depuis 2 ans, je vous propose d’aborder les risques récurrents identifiés lors des projets sur lesquels j’ai travaillé. Afin d’éviter de perdre du temps ou de ne pas arriver au niveau de qualité attendue, je parcours toujours ces éléments lors de mes kick-offs (réunions de lancement) pour les sécuriser au maximum.
Une gouvernance floue, un cahier des charges incomplet ou un défaut de communication créent des blocages coûteux qui peuvent être évités. Voici comment vous prémunir de ces trois risques organisationnels qui menacent la réussite de votre projet dès son lancement.
Lors du lancement d’un projet Web, l’équipe client et l’équipe agence sont présentées. C’est à l’occasion de ces présentations que je m’assure d’identifier les personnes en charge de la validation des livrables du projet. S’il est possible d’avoir un validateur différent pour le DAT (Document d’Architecture Technique), les prototypes ou les spécifications fonctionnelles, il reste indispensable que ce validateur soit clairement identifié.
Je conseille aussi de mettre en place un tableau de type RACI (Responsable - Approbateur - Consulté - Informé), dans lequel est ajoutée la mention de la personne en charge de la validation de chacun de ces livrables.
Une fois les validateurs identifiés, il reste à confirmer leurs dates de congés et à vérifier sur le planning prévisionnel du projet que la validation de/des phase(s) dont ils sont responsables ne tombe pas pendant lesdits congés.
En cas de conflit entre les différents interlocuteurs du projet, la présence d’un validateur formellement identifié fera gagner un temps précieux et évitera des allers-retours contradictoires.
Il arrive qu’une même phrase d’un cahier des charges soit interprétée très différemment par le client, le chef de projet, l’UX designer et le développeur. Or, plus le cahier des charges sera précis, moins il y aura de risques d’incompréhensions.
Lors de la phase de réponse à un appel d’offres, demandez à votre agence de vous fournir une matrice des exigences, qui détaille, fonctionnalité par fonctionnalité, sa compréhension de chacune des demandes clients et la façon dont elle compte y répondre. À noter aussi que la matrice identifie ce qui n’est pas inclus dans le périmètre (si le besoin est pris en charge par une autre fonctionnalité/gabarit très proche, par exemple). Ce document est une étape intermédiaire entre le cahier des charges et le document de spécifications fonctionnelles.
Lors de la phase de conception, assurez-vous également que votre agence utilise cette matrice pour éclaircir les éventuels points flous du cahier des charges.
À l’issue de la phase de conception, les réunions peuvent avoir tendance à s’espacer. Le développement est lancé, et l’agence a moins besoin d’interactions avec le client pour avancer. Il devient donc difficile pour ce dernier de suivre l’avancement du projet, tout comme il est compliqué pour l’agence d’obtenir des réponses à ses questions.
Pour éviter ça, je conseille de conserver des réunions hebdomadaires (comités projet ou COPROJ) entre l’agence et le client, afin que les interlocuteurs du projet puissent poser toutes leurs questions, de même que parler du planning et des prochaines étapes.
Bien sûr, ces réunions doivent toutes être tracées dans un compte rendu, qui liste les décisions prises et les actions à mener par chaque interlocuteur du projet.
API instables, choix technologiques inadaptés ou problèmes d’interopérabilité, autant d’éléments qui peuvent créer des blocages critiques souvent détectés trop tard et compromettre la réussite de votre projet.
Démarrer un projet qui doit s’interfacer avec des APIs encore en cours de spécifications ou de développement revient à construire son futur site sur du sable.
Si les APIs ne sont pas encore spécifiées, la phase de conception ne pourra pas se faire correctement (absence du détail des données récupérables, de leur format, etc.), car les prototypes, maquettes et spécifications seraient basés sur des suppositions de données récupérables.
Si les APIs sont encore en cours de développement, la phase de spécification ne pourra se faire qu’en se basant sur les spécifications des API, et les développeurs devront travailler avec des données fictives susceptibles de générer des surprises une fois le projet interfacé avec l’API finalisée.
Dans tous les cas, gérer la recette de l’API en même temps que la recette du site génère beaucoup de frustration pour les utilisateurs qui n’ont pas accès aux données de l’API (via Postman, par exemple). En cas de problème, est-ce la donnée de l’API qui n’est pas bonne ? Est-ce que l’information n’est pas correctement récupérée/mise à jour sur le site ?
Lancer le développement d’un site dont l’API est encore en cours de développement est par conséquent à éviter. Et si ce n’est pas possible de faire autrement, attendez au moins que le document de spécification des APIs soit finalisé, afin de sécuriser votre propre phase de conception et créer des jeux de tests (mocks) stables avec des contrats d’interfaces figés.
De mauvais choix techniques font courir un risque important à votre projet. L’utilisation de technologies instables, d’architectures sur ou sous dimensionnées, ou la dépendance à des services tiers fragiles peuvent compromettre la pérennité du projet.
En tant que cheffe de projet fonctionnel, je ne suis pas toujours en mesure d’évaluer la pertinence technique des choix proposés par l’équipe de développement. Toutefois, j’ai appris à poser les bonnes questions pour détecter les risques.
J’ai ainsi tendance à me méfier des technologies trop récentes que mes équipes techniques voudraient tester. Un projet client ne doit pas être un terrain d’expérimentation. Les technologies « bleeding edge » (ou technologies de pointe) manquent par exemple souvent de documentation, en plus d’avoir des communautés restreintes, d’évoluer rapidement et de générer de la dette technique.
Je fais aussi attention aux frameworks ou CMS en fin de vie, en vérifiant les dates de fin de support et les feuilles de route. En effet, un CMS obsolète expose le client à des failles de sécurité.
En phase de conception, lors des choix d’architecture, je questionne également l’adéquation entre les besoins réels et la complexité technique proposée. Par exemple, un site vitrine n’a pas besoin d’une architecture microservices, tout comme un e-commerce à fort trafic ne peut se contenter d’un hébergement mutualisé.
À ce sujet, le document de spécifications doit lister les différents services tiers du projet (APIs, plugins, services de paiement, etc.) et informer sur leur pérennité. Et je parle d’expérience. J’ai effectivement vécu l’arrêt brutal d’un service de géolocalisation, qui a impacté 15 projets simultanément et nécessité une solution de contournement (qui aurait pu être anticipée) pour garantir une continuité de service.
Lors de la conception technique du projet, il est important de cartographier l’ensemble des systèmes avec lesquels le nouveau site devra communiquer, en sachant que l’intégration avec l’écosystème informatique existant du client est souvent plus complexe que prévu.
Il n’est pas simple de connecter un site en cours de développement avec des ERPs (Enterprise Resource Planning ou Progiciel de gestion intégré), CRMs (Customer Relationship Management ou Système de gestion de la relation client) ou BDDs clients (base de données) qui n’ont pas été conçus pour dialoguer ensemble. En effet, les formats de données sont rarement compatibles. Une tâche en apparence simple comme « Importer des données produits » peut vite se transformer en casse-tête quand les prix sont en centimes dans un système, en euros dans un autre, et utilisent parfois des devises différentes.
Je conseille donc de travailler sur des fichiers de mapping dédiés, qui reprennent les formats de départ et d’arrivée de chaque donnée, ainsi que les scripts nécessaires pour d’éventuelles conversions.
L’authentification unique (SSO) est un autre piège récurrent. Il arrive effectivement que seul un SSO de prod existe, ce qui n’est pas idéal pour se brancher à des environnements de test.
Pour m’en prémunir, je demande des comptes de test au client dès le début du projet (ces derniers pouvant être longs à créer côté DSI), car sans comptes de tests, impossible de vérifier le bon fonctionnement du SSO.
Concernant les synchronisations à prévoir entre le site et une base de données tiers, il faut peser le pour et le contre entre une synchronisation en temps réel, qui peut saturer les systèmes clients, et une synchronisation en batch, qui peut créer des incohérences de données temporaires.
Si vous optez pour du temps réel, il faudra dimensionner les serveurs en conséquence avec une architecture scalable (load balancing, mise en cache) et implémenter des mécanismes de limitation du taux de requêtes (rate limiting), voire créer des files d’attente pour se protéger des pics de charge.
Si vous optez pour une synchronisation en batch, il faudra définir une fréquence adaptée aux enjeux métier (quotidienne ? toutes les heures ?), prévoir un système de gestion des conflits (pour traiter des données modifiées simultanément des deux côtés), implémenter des mécanismes de reprise sur erreur avec logs détaillés, et informer les utilisateurs des délais de mise à jour (pour éviter toute confusion).
Planning trop optimiste, sous-estimation des phases de validation ou découverte de fonctionnalités non budgétées, tous ces points peuvent rapidement transformer un projet Web maîtrisé en gouffre financier et menacer directement sa rentabilité.
« Un jour, j’irai vivre en théorie. Parce qu’en théorie, tout se passe bien. » P. Desproges
Lors du lancement d’un projet, on est encore en théorie et on a tendance à être trop optimiste. D’expérience, les délais de validation des livrables (prototypes, maquettes, spécifications, recette, etc.) sont souvent sous-estimés. Prévoyez donc du temps de réflexion et de recul, car vous pourrez difficilement valider les maquettes graphiques à la sortie de leur réunion de présentation.
Veillez également à ce que votre agence intègre une marge de sécurité sur le planning, de l’ordre de 20 à 30 % de temps de marge (par rapport aux temps vendus sur le chiffrage), et ce, pour absorber d’éventuels retards, absences, etc.
Vous voulez en savoir plus sur les causes de retard dans les projets digitaux ? Ma collègue Carène a rédigé un article sur le sujet.
Il est aussi important de prévoir un temps de recette suffisamment long, puisque vous aurez souvent d’autres tâches à gérer en parallèle de la recette ou même des contretemps. Or, le temps de saisie de contenu doit aussi être anticipé, en tenant compte de la disponibilité réelle des personnes en charge de cette mission.
Malgré un devis détaillé, il arrive régulièrement que des fonctionnalités soient découvertes en cours de projet. Une fonctionnalité de recherche « Simple » peut finalement ne pas suffire et se transformer en moteur de recherche avancée avec filtres, suggestions et géolocalisation.
Les évolutions réglementaires peuvent aussi générer des développements non budgétés. En 2018, la mise en conformité RGPD a par exemple généré des surcoûts sur un grand nombre de projets. À ce propos, je vous conseille d’effectuer une veille réglementaire en début de projet pour identifier les textes en cours d’adoption.
À noter qu’il arrive aussi que des besoins de performances soient découverts à la suite des tests de montée en charge, au point de générer une montée en gamme de l’hébergement ou la mise en place d’une solution de mise en cache (CDN).
La migration des données existantes est, elle aussi, souvent sous-estimée. Nettoyer, formater et importer des années de données clients peut en effet relever de l’archéologie numérique. Et malheureusement, il n’est pas toujours possible d’auditer la qualité des données existantes avant de chiffrer le temps nécessaire à leur import. Je conseille par conséquent de planifier des phases de nettoyages des données, en amont des imports.
Concrètement, une réserve budgétaire de 15 à 20 % du budget global peut s’avérer utile pour gérer tous ces imprévus.
Équipes sous-qualifiées, départs imprévus ou perte de connaissances critiques peuvent paralyser un projet en quelques jours. Ces risques humains majeurs qui compromettent la continuité et la qualité de votre projet Web doivent donc être anticipés autant que possible.
Dès la phase de réponse à un appel d’offres, certaines intégrations spécifiques peuvent nécessiter des compétences techniques poussées (SAP pour connexion à un ERP, optimisation SEO pointue, API de paiement très spécifique, etc.). Si des formations s’avèrent nécessaires à la réalisation du projet, celles-ci doivent être planifiées et budgétées en amont.
Certaines compétences métiers sont tout aussi importantes. Pour travailler sur un site e-commerce dans le secteur de la mode, il est plus que recommandé de comprendre les problématiques de gestion des stocks, de saisonnalité, de déclinaisons produits, etc. Idem pour une collectivité, où il faut plutôt bien maîtriser les contraintes de marchés publics et d’accessibilité.
À ce titre, je vérifie systématiquement le niveau d’expertise de mes équipes pour qu’il soit adapté au contexte du projet. En effet, une équipe uniquement composée de juniors ne pourra pas tenir les délais sans accompagnement, alors qu’une équipe uniquement composée de profils seniors aura un impact important sur la rentabilité du projet. Trouver le bon équilibre est essentiel.
Un départ impromptu peut mettre en péril un projet entier si ce dernier est mal documenté et que les connaissances n’ont pas été partagées.
Côté client, le départ d’un interlocuteur clé est aussi un risque, notamment si certains arbitrages ou certaines spécificités du projet n’ont pas été documentés. Son remplaçant risque de ne pas comprendre les choix qui ont été faits.
Ne pas anticiper les absences (formations, congés, départs, etc.) est un autre risque important. La connaissance ne peut pas reposer sur une seule et unique personne, sous peine que le projet se retrouve bloqué en l’absence de cet interlocuteur clé. Pour prévenir ce risque, je m’assure que le projet est documenté au maximum et je prévois des passations entre les membres d’une même équipe avant leurs congés et/ou formations.
Autre sujet clé, la gestion des accès aux mots de passe. Sur ce créneau, je conseille l’utilisation de gestionnaires de mots de passe d’équipe (Bitwarden, Dashlane, LastPass, etc.), dans lesquels centraliser et partager tous les accès (serveurs, comptes clients, outils, etc.).
RGPD, accessibilité numérique et éco-conception Web sont devenus des obligations légales qu’il faut intégrer dès la conception sous peine de refonte coûteuse. Mais ces évolutions réglementaires majeures transforment les exigences de qualité et conformité des projets Web.
Le Règlement Général sur la Protection des Données définit le cadre dans lequel les organisations peuvent traiter les données personnelles. Depuis le 25 mai 2018, l’ensemble des organisations qui traitent ou stockent des données à caractères personnels doivent respecter ce cadre.
L’objectif du respect des règles du RGPD est de protéger les données personnelles de vos utilisateurs contre la cybercriminalité et l’espionnage d’État, mais aussi de protéger leur vie privée.
En cas de manquement à ces règles, des sanctions financières s’appliquent et peuvent représenter :
Lors de la conception de votre projet Web, je recommande donc de porter une attention particulière à la gestion de vos formulaires (consentement au recueil de données), à vos emailings, à vos CGU (Conditions générales d’utilisation), etc. Vous trouverez le détail de toutes ces règles sur cet article dédié à la gestion du RGPD.
L’accessibilité numérique est une démarche qui consiste à rendre les outils numériques utilisables à toute personne, quels que soient ses handicaps physiques ou mentaux. Attention, elle n’est plus une option depuis le décret de 2019 qui impose aux organismes publics (et depuis 2025 à certaines entreprises privées) de respecter les standards WCAG 2.1 niveau AA.
En fin de projet, si l’accessibilité n’a pas été correctement prise en compte, il est probable que des corrections longues et coûteuses soient nécessaires pour rectifier le tir. De plus, au-delà desdites corrections à appliquer suite aux audits d’accessibilité, les amendes peuvent atteindre 25 000 € par an et par site non conforme.
Les règles du Référentiel Général d’Amélioration à l’Accessibilité (RGAA) listent un grand nombre d’obligations qui impactent toutes les phases du projet. Là où l’UX designer doit penser contrastes colorés, navigation au clavier et structuration sémantique, l’UI designer doit adapter sa charte graphique. De leur côté, les développeurs doivent maîtriser les attributs ARIA et les technologies d’assistance.
En bref, travailler avec des équipes formées aux bonnes pratiques de l’accessibilité est devenu indispensable. Pour plus d’informations, ma collègue Leslie a rédigé un article complet sur le sujet.
L’éco-conception Web vise à réduire l’impact environnemental des sites internet tout au long de leur cycle de vie, de leur conception à leur hébergement. Et cette pratique devient un enjeu majeur, tant par conscience environnementale, que par anticipation des futures réglementations.
Si la loi REEN de 2021 impose déjà des obligations de réduction de l’empreinte environnementale du numérique, d’autres textes sont en préparation au niveau européen.
La bonne nouvelle ? Performance et écoconception vont de pair. Un site rapide consomme moins de ressources serveur et moins de batteries côté utilisateur. Les techniques d’optimisation (compression d’images, minification du code, lazy loading) bénéficient aux deux objectifs.
Évidemment, une conception sobre nécessite aussi de repenser l’expérience utilisateur, en optimisant le poids des pages, en limitant le nombre et le poids des images, etc. À ce sujet, des outils simples comme EcoIndex ou GreenIT Analysis donnent une note environnementale aux pages. C’est un bon moyen pédagogique de suivre leur évolution.
Matrices de suivi, marges de sécurité budgétaires et gouvernance adaptée transforment la gestion de projet d’un art en une science reproductible. Quatre bonnes pratiques éprouvées sécurisent ainsi l’exécution et la réussite de votre projet Web.
Je fais partie de ces personnes qui apprécient un tableau Excel bien construit, d’autant plus que j’y élabore les matrices avec lesquelles je travaille.
Parmi elles, la matrice des exigences est indispensable. En effet, elle permet, pour chaque demande du cahier des charges client, de documenter notre compréhension de la demande et de la solution proposée.
Il en va de même avec la matrice RACI (Responsible, Accountable, Consulted, Informed), qui, au-delà de la simple identification des intervenants, permet de savoir qui a le pouvoir de décision finale. Faire la distinction entre la personne « Responsible » (qui fait) et la personne « Accountable » (qui décide) évite les blocages quand les interlocuteurs ne sont pas tous du même avis.
Enfin, la matrice de traçabilité des risques me sert de tableau de bord. Chaque niveau de risque y est identifié avec son niveau d’impact, sa probabilité et les solutions possibles. Elle est parcourue à chaque comité projet.
Notez que ces matrices sont partagées entre les différents interlocuteurs des projets (sur Sharepoint), et que ces derniers peuvent les maintenir à jour.
L’expérience m’a malheureusement appris que les projets qui respectent le planning initial sont l’exception plutôt que la règle. Intégrer des marges de sécurité aux délais estimés relève donc du réalisme, et non du pessimisme.
J’intègre ainsi systématiquement 20 à 30 % de marge sur chaque phase du projet. 20 % pour les phases les plus sûres, comme l’intégration HTML/CSS, et 30 % sur celles qui comportent plus de risques, comme l’intégration d’une application tierce.
La phase de recette bénéficie aussi d’une marge de sécurité spécifique (minimum 30 %), car il arrive trop souvent que le temps nécessaire à la recette soit sous-estimé au point de la bâcler. De même, les corrections issues de la phase de recette sont matérialisées sur le planning.
Côté finances, je recommande de prévoir entre 10 et 15 % de budget supplémentaire pour gérer les imprévus (nouveaux besoins fonctionnels, évolutions réglementaires). Même s’il n’est pas systématiquement consommé, il peut éviter des arbitrages inconfortables en cours de projet.
Bien entendu, j’explique toujours l’utilité de ces marges au client en précisant qu’elles protègent la qualité finale du projet.
En guise de bonnes pratiques, je recommande aussi l’organisation d’un comité projet hebdomadaire (COPROJ). Cette réunion permet en effet d’échanger sur les éléments du projet, de présenter les options/solutions à arbitrer, de présenter et valider les documents projets, etc. J’y partage en plus la matrice des risques, en plus d’y faire un suivi des indicateurs qualité.
Les participants à cette réunion peuvent varier en fonction des phases du projet (équipes UX/UI en phase de conception, lead dev en phase de développement, etc.), mais de manière générale, cette réunion est opérationnelle.
Aux grandes étapes du projet Web (validation des maquettes, specs, livraison en prod, etc.), je conseille également l’organisation de comités de pilotage (COPIL). Lors de cette réunion, un échange sur la qualité globale des prestations est prévu, ainsi qu’une synthèse des actions du comité projet. Des arbitrages plus stratégiques peuvent également y être faits. À cette occasion, je propose aussi un suivi du planning et un suivi financier.
À noter que lors des COPIL, les personnes « Accountable » du RACI doivent être présentes, puisqu’il s’agit d’une instance plus stratégique.
Pour les COPROJ comme pour les COPIL, un ordre du jour est communiqué avant la réunion, et un compte rendu est systématiquement partagé par la suite.
Les évolutions de la législation (RGPD, accessibilité, éco-conception, etc.) peuvent impacter significativement un projet en cours. Il vaut donc mieux les anticiper que les subir.
Certaines évolutions sont prévisibles, comme la généralisation des obligations d’accessibilité aux entreprises privées, le renforcement des exigences environnementales, les nouvelles règles sur les cookies, etc., ce qui me permet de les intégrer dès la phase de conception du projet.
Les évolutions imprévisibles, quant à elles, peuvent être absorbées grâce aux marges prises sur le planning. Néanmoins, elles feront probablement l’objet d’une vente additionnelle, n’étant pas prévues dans la matrice des exigences.
Mon conseil : créez une checklist réglementaire par secteur d’activité et mettez-la à jour régulièrement. Elle vous fera gagner un temps précieux sur chaque nouveau projet.
Tous ces risques sont ceux que j’ai le plus rencontrés lors des projets que j’ai gérés en tant que Cheffe ou Directrice de projet. Et je les rencontre encore aujourd’hui. Je vous encourage donc à les anticiper le plus en amont possible.
Par ailleurs, les équipes AMOA (Assistance à maîtrise d’ouvrage) d’Adimeo peuvent vous accompagner dans l’anticipation et la gestion de ces risques. Contactez-nous !
Crédit photo : jacoblund