Beaucoup de dirigeants qui contactent une équipe pour réaliser un site officiel commencent par : « Donnez-moi d'abord un prix. »
Résultat : le devis arrive, et les deux parties ne parlent pas du tout de la même chose. Vous pensez que la publication d'actualités et le formulaire de contact en ligne sont inclus, alors que le prestataire n'a compté que cinq pages statiques. À la troisième version, le délai a pris un mois de retard et le budget a été dépassé.
Le problème ne vient pas du développeur, mais du fait que les documents de spécifications ne sont pas prêts. Le développement d'un site web consiste essentiellement à traduire des idées exprimées oralement en une liste exécutable. Plus cette liste est claire, plus le devis est précis et moins il y a de reprises.
Voici, dans l'ordre réel d'un projet, ce qu'il faut préparer avant le démarrage.
1. Commencez par écrire les objectifs et le périmètre, sans vous précipiter sur la liste des pages
Le premier document n'est pas la liste des pages, mais le « pourquoi ».
Écrivez clairement trois choses : quel problème ce site d'entreprise doit résoudre (acquisition de clients, présentation de la marque, recherche de partenaires, support après-vente) ; comment mesurer le succès (nombre de prospects par mois, nombre de demandes de renseignements, durée de visite) ; et ce qu'il ne faut pas faire.
Le dernier point est le plus souvent négligé, et c'est aussi celui qui permet d'économiser le plus. Par exemple, une entreprise spécialisée dans les équipements industriels qui refait son site officiel a clairement indiqué : « Cette phase ne comprend ni le paiement en ligne ni un système d'adhésion. » Une fois le périmètre délimité, le devis est immédiatement passé de plus de 200 000 à une fourchette raisonnable.
Piège à éviter : écrire comme objectif « améliorer l'image de marque » revient à ne rien écrire. Remplacez-le par « permettre aux clients de nous trouver lorsqu'ils recherchent une référence produit, et de soumettre directement une demande de devis ». Le développeur saura alors qu'il faut prévoir une recherche produit et un formulaire.
2. La liste des pages et la structure des rubriques doivent correspondre à des pages concrètes
Utilisez un tableau pour lister toutes les pages : nom de la page, niveau hiérarchique, contenu principal, et si elle doit être modifiable depuis l'administration.
La page d'accueil, la page « À propos », le centre de produits, les actualités et la page de contact ne constituent que la structure de base. Ce qui influence réellement la charge de travail, ce sont les détails : le centre de produits doit-il avoir plusieurs niveaux de catégories, faut-il un filtrage par caractéristiques, les actualités doivent-elles prendre en charge le regroupement par tags ?
Exemple concret : une entreprise de services en chaîne qui développe un mini-programme de réservation avait d'abord seulement indiqué « pouvoir réserver, c'est suffisant ». Après avoir complété la liste des pages, on a découvert qu'il fallait cinq pages : liste des magasins, prestations, choix des créneaux horaires, statut de la commande et règles d'annulation. La charge de travail a doublé.
Piège à éviter : ne remplacez pas une description par « similaire à tel site ». Un site de référence ne peut indiquer qu'un style, pas les limites fonctionnelles.
3. La description des fonctionnalités doit préciser « qui fait quoi, dans quelles conditions »
Décrivez chaque fonctionnalité en une phrase : rôle, action, résultat. Par exemple : « Un visiteur clique sur “demande de devis” sur la page produit, saisit son nom et son téléphone, puis après envoi, la demande apparaît dans la liste des prospects à traiter dans l'administration et un e-mail est envoyé au commercial. »
Le système d'administration doit être décrit particulièrement en détail. Qui a les droits, quels champs peuvent être modifiés, si les données peuvent être exportées, si les opérations sont enregistrées : tout cela détermine le temps de développement.
S'il s'agit d'un développement d'App ou de mini-programme, il faut aussi ajouter le mode de connexion, les notifications de messages, ainsi que les processus de paiement et de remboursement. Pour tout ce qui concerne le paiement, confirmez à l'avance les qualifications de l'entité et le délai de demande d'accès aux interfaces, afin de ne pas découvrir à la fin du développement que le service n'est pas activé.
Piège à éviter : considérer les quatre mots « gestion back-office » comme une exigence. Cela comprend au minimum cinq blocs : connexion, droits d'accès, création/modification/suppression/consultation de contenu, téléversement d'images et journaux.
4. Les contenus et références visuelles doivent être préparés en parallèle
Les documents de spécifications doivent inclure une liste des éléments à fournir : fichiers sources du logo, couleurs de marque, photos de produits, présentation de l'entreprise, certificats et qualifications, coordonnées, informations d'enregistrement.
Beaucoup de projets sont bloqués en attente de contenus : le développeur attend, mais le délai continue de courir. Il est recommandé de convenir : qui fournit les éléments, à quelle date ils doivent être disponibles, et quoi utiliser en cas d'absence.
Pour la partie visuelle, fournissez trois à cinq sites de référence et précisez si vous aimez « leur mise en page » ou « leurs couleurs », afin d'éviter que le développeur ne devine.
Piège à éviter : télécharger directement des images depuis le site de quelqu'un d'autre. Les risques de droits d'auteur et les problèmes de netteté entraîneront des reprises plus tard.
5. Fixez à l'avance les critères d'acceptation et les contraintes techniques
Les critères d'acceptation doivent être vérifiables : plage de compatibilité avec les navigateurs principaux et les modèles de téléphones, objectif de vitesse d'ouverture des pages, taux de réussite de soumission des formulaires, fluidité des opérations dans l'administration.
Les contraintes techniques incluent : utiliser ou non le serveur existant, faut-il s'interfacer avec un système existant, faut-il une conformité de niveau de sécurité ou des tests de sécurité, y a-t-il des exigences SEO (par exemple structure des URL, configuration des TDK).
Pour ce qui concerne les données et les comptes, il est recommandé de prévoir dans le contrat la réalisation d'un test de sécurité du site afin de vérifier les vulnérabilités courantes. Ce n'est pas une étape superflue : le coût d'un site d'entreprise piraté ou d'une fuite de données est bien supérieur à celui du test.
Piège à éviter : écrire comme critère d'acceptation « conforme aux exigences ». Remplacez par « sur Chrome, Safari et les principaux modèles Android, la page d'accueil et la page produit ne présentent aucun décalage, et après soumission du formulaire, l'enregistrement apparaît dans l'administration en moins de 3 secondes ». Les litiges seront bien moins nombreux.
Dans quels cas faire appel à MIC Studio
Si vous avez déjà des objectifs commerciaux clairs, mais que vos besoins sont dispersés dans des historiques de discussion et dans votre tête, et que vous avez besoin de quelqu'un pour les organiser en documents avant le développement ; ou si le projet concerne la refonte d'un site d'entreprise, le développement d'un mini-programme, le développement d'une App, un système d'administration, avec en plus des interfaces à connecter et des tests de sécurité, ce type de projet transversal gagne à être confié à une seule équipe pour être mené de manière coordonnée.
La méthode de MIC Studio consiste d'abord à passer en revue avec vous les cinq documents ci-dessus, à confirmer le périmètre et les critères d'acceptation, puis à proposer un planning et un devis. Démarrer sans avoir clarifié les besoins épuise les deux parties.
Trois conseils concrets
1. Avant le démarrage, écrivez sur une page les objectifs, ce qu'il ne faut pas faire et la liste des pages, envoyez-la au développeur pour confirmation, et conservez une trace par signature ou par e-mail.
2. Rédigez la description des fonctionnalités une par une selon le modèle « rôle — action — résultat », en listant séparément l'administration et le processus de paiement ; plus c'est précis, plus le devis est juste.
3. Joignez la liste des contenus et les critères d'acceptation en annexe du contrat, en convenant de la date de mise à disposition des éléments et de la manière de traiter les éléments manquants, afin d'éviter les contestations sur les délais.
Les documents de spécifications ne sont pas une formalité : c'est la seule référence fiable entre vous et le développeur. Deux jours passés à bien les rédiger peuvent éviter deux semaines de reprises par la suite.