Lire une proposition de développement : le guide du fondateur

Une proposition de développement transforme votre brief en engagements : ce qui sera construit, pour quand, pour combien, et ce qui se passe quand quelque chose change.

La règle de travail est simple : si un détail n’est pas écrit, partez du principe qu’il n’est pas inclus.

Un bon périmètre décrit ce qu’un utilisateur peut faire, pas seulement le nom des écrans. « Les utilisateurs peuvent s’inscrire avec leur e-mail ou Google et réinitialiser leur mot de passe » se vérifie. « Module d’authentification », non.

Vérifiez que les rôles utilisateur, les parcours clés et les outils d’administration sont listés séparément. Une interface d’administration s’oublie facilement dans un brief et coûte cher à ajouter ensuite.

Une proposition claire liste ce qui n’est pas inclus, par exemple la rédaction des textes, les traductions, la publication sur les stores, les abonnements à des services tiers ou l’hébergement après le lancement.

S’il n’y a pas de section sur les exclusions, demandez-en une. Tout ce que vous pensiez inclus et qui ne l’était pas reviendra plus tard sous forme de demande de changement.

Pas besoin d’être ingénieur, mais après lecture, vous devez pouvoir répondre à ces questions :

Avec quoi le produit sera-t-il construit, et pourquoi cette stack pour votre produit précisément ?

À qui appartiennent le code et les comptes : hébergement, nom de domaine, stores d’applications, mesure d’audience ?

Où sera-t-il hébergé, et combien cela coûtera-t-il à peu près chaque mois après le lancement ?

Le code sera-t-il assez documenté pour qu’un autre développeur puisse le reprendre ?

Une bonne agence explique ses choix simplement. « C’est ce qu’on utilise toujours » n’est pas une raison.

Une date de livraison unique ne dit pas grand-chose. Cherchez des jalons qui donnent chacun quelque chose à voir : maquettes validées, version fonctionnelle sur un lien de test, version prête au lancement.

Demandez à quelle fréquence vous verrez l’avancement. Un point hebdomadaire est une base raisonnable ; une seule démo tout à la fin est un risque.

Vérifiez si la proposition parle de tests, de performance et d’accessibilité, ou seulement de fonctionnalités.

Cherchez du concret : quels navigateurs et appareils sont pris en charge, quelles performances le produit doit atteindre, et qui le teste avant le lancement.

Vérifiez exactement ce que couvre le prix et comment les paiements sont répartis. Un acompte puis des paiements liés aux jalons, c’est la norme ; 100 % d’avance, non.

Trouvez la procédure de changement. Elle doit expliquer comment les nouvelles demandes sont chiffrées et validées avant que quiconque s’y mette.

Beaucoup de propositions s’arrêtent au jour du lancement. Demandez la suite : y a-t-il une période de garantie pour les bugs, combien de temps dure-t-elle, et comment le travail continu est-il facturé ?

Un lancement sans plan pour les corrections et les mises à jour, c’est là que beaucoup de produits s’enlisent sans bruit.

Qu’est-ce qui est exclu, exactement ?

Qui travaillera sur le projet au quotidien ?

Que se passe-t-il si nous devons changer le périmètre ?

À qui appartiendront le code et chacun des comptes à la fin ?

Quel support est inclus après le lancement ?