30 questions récurrentes pour chiffrer un développement web

Plus un cahier des charges est détaillé, plus notre devis est précis. Logique. Et comme la plupart du temps nos clients sont hyper exhaustifs, voici la liste des questions que nous n’avons (presque) jamais besoin de poser pour affiner notre chiffrage ou valider nos recommandations techniques !

Les classiques

Navigateurs cible

A l’heure de Chrome 63 et d’Edge 16, les comportements des navigateurs tendent à s’harmoniser, ce qui est une bonne chose pour les développeurs. Malgré tout, on nous demande encore des sites compatibles IE9 voire IE8… souvent pour les grandes entreprises qui prennent du temps à mettre à jour l’ensemble des postes de leur parc informatique. Savoir pour quels navigateurs on développe est essentiel : cela conditionne la faisabilité de certaines fonctionnalités et peut avoir un impact budgétaire.

Planning

Un planning serré nécessite une plus grosse équipe, des développements en parallèle susceptibles de se chevaucher… Plus le planning est souple, plus le devis est indulgent !

Tracking

Avez-vous prévu de mettre en place une solution de tracking ? Avec quelle(s) solution(s) (Google Analytics, Omniture…) ? Y aura-t-il du tracking sur les interactions utilisateur ou uniquement à l’arrivée sur chaque page ? Selon la complexité de la demande, nous pourrons avoir besoin d’un plan de taggage.

SEO

Il est fréquent de trouver dans les cahiers des charges une mention du type « mettre en oeuvre les bonnes pratiques SEO »… développeur débrouille-toi !
Certes nous pouvons faire attention à l’imbrication des balises h, à rajouter des balises alt sur les images, à renseigner les metas title et description… mais les connaissances du développeur en matière de SEO s’arrêtent généralement là. Pour aller plus loin il faut faire appel à des spécialistes du référencement. Ces derniers travaillent sur la base des créas ou des wireframes, et fournissent un document avec des recommandations précises, allant du simple agencement des balises HTML classiques jusqu’à l’implémentation d’un schéma de micro-données complexe. Avoir ces recommandations avant le début du développement permet non-seulement d’évaluer avec précision la charge de travail côté intégration, mais aussi d’éviter d’avoir à refaire une partie du code.

Site événementiel

Pour un site événementiel dont la durée de vie est définie dans le temps, il est souvent nécessaire d’afficher une page de fin d’opération. Nous avons besoin de savoir si cette page existera, ce qu’elle contiendra et à quel moment nous devrons effectuer la bascule.

Hébergement

Qui gère l’hébergement ? Quelles sont les caractéristiques du serveur, en particulier la version de PHP ?
La configuration de l’hébergement conditionne parfois le choix de la technologie.

Déploiement

Nous pouvons nous charger du déploiement, mettre en place des scripts d’intégration continue… ou bien laisser faire le client !
Tout cela s’étudie, en fonction du besoin. Quand cela est possible, nous donner la main sur le déploiement est parfois plus efficace pour tout le monde.

Maintenance

La plupart des sites basés sur des CMS nécessitent a minima des mises à jour de version. Parlons-en !

L’interface

Quel comportement responsive pour les grandes résolutions ?

Dans le cas d’un site responsive, nous recevons la plupart du temps une créa desktop de largeur 1280 px, une créa mobile en 640 px et éventuellement une version tablette en 720 ou 1024. Mais la plupart du temps, le cas des résolutions supérieures n’est pas abordé. Pourtant, ce point nécessite d’être prévu en amont du développement. Le choix se résume généralement à 2 options : bloquer l’affichage à une largeur max ou bien gérer un affichage du background bord à bord. Passer d’un fonctionnement à un autre une fois le site développé peut s’avérer dans certains cas périlleux, et en tout cas chronophage !

Animations

Le temps d’intégration peut varier du simple au double en fonction du degré d’animation souhaité sur les apparitions, transitions, roll-overs… Il est donc important de définir le degré d’animation souhaité.
Il est même envisageable de prévoir certaines animations en DA et de nous les fournir sous forme de sprite. Y penser diminue l’enveloppe du développement et permet de réaliser des animations plus complexes que via du JS / CSS.

Gestion des erreurs dans les formulaires

La question se pose systématiquement : quand devons-nous afficher les erreurs d’un formulaire ?
Plusieurs options, de la plus simple à la plus complexe :
– au clic sur le bouton de soumission, avec rechargement de la page
– au clic sur le bouton de soumission, sans recharger la page
– dès que l’utilisateur sort du champ (perte de focus)

Champs de recherche

Sur quels critères devons-nous baser la recherche ? Devons-nous mettre en place un système d’auto-complétion ?
Ces réponses nous permettront d’affiner notre devis.

L’administration des contenus

Localisation

Le site est-il multilingue ? Combien de langues ? Devons-nous intégrer des typos exotiques ?
Qui se charge d’intégrer les textes localisés ?

Quels contenus administrables ?

Il nous arrive de n’avoir aucune information concernant l’administration des contenus. Ce point est pourtant essentiel car il conditionne le temps de développement back ou de paramétrage du CMS utilisé.
Afin de gagner du temps en développement, une optimisation consiste à renseigner tous les wordings d’interface (boutons, menus, titres de pages…) dans des fichiers de traduction plutôt que de les rendre éditables dans le backoffice. Mais cela peut ne pas convenir à tous. Avoir cette info est donc un plus.

Quels rôles utilisateurs ?

Dans le cas d’un site administrable, il arrive d’avoir besoin de plusieurs types d’accès au backoffice : super admin, rédaction d’articles, gestion des commandes… les rôles peuvent varier en fonction des besoins du client.

Inscription newsletter

Il est fréquent de trouver sur les formulaires un optin d’inscription à une newsletter. S’il est présent sur la créa, il n’est pourtant pas souvent explicité dans le cahier des charges : que devons-nous faire de cette inscription ? S’agit-il de l’enregistrer en BDD ? Devons-nous brancher une API permettant de faire le lien avec un outil de newsletter (type Mailchimp) ? Avez-vous besoin d’une fonctionnalité d’extract en CSV dans l’admin ?

Documentation

Devons-nous prévoir une documentation pour l’interface d’administration ? Tous les clients n’en ont pas besoin : certains sont déjà des champions de WordPress ou Drupal !

Les sites e-commerce

Pour un site e-commerce, l’élaboration du chiffrage nécessite de connaître les informations suivantes :

– Les règles pour le calcul des coûts de livraison
– Les règles de gestion des horaires
– La gestion des stocks et le fonctionnement du système de caisse
– Un ordre de grandeur du nombre de produits
– La logique de produits liés (cross-selling)
– Les logiques de promotion et de bundle de produits
– Les moyens de paiement à mettre en place
– Le nombre de devises avec lesquelles l’utilisateur pourra payer
– Des précisions sur un éventuel interfaçage avec un ERP

Un cahier des charges à nous soumettre ? Contactez-nous ! Nous nous ferons un plaisir de vous poser toutes ces questions, et sûrement d’autres !

MERCI POUR LE PARTAGE !
Share on Facebook
Facebook
Tweet about this on Twitter
Twitter
Share on LinkedIn
Linkedin

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *