Pour information, dans notre équipe (Wixiweb), il nous arrive de refuser 1 projets sur 2 parce que le projet nous semble pas viable ou que le porteur de projet ne semble pas assez « mature » pour s’y attaquer.

Lorsque c’est le cas, nous essayons de conseiller, en avant vente, en indiquant nos inquiétudes et en proposant des axes à retravailler mais dans des cas où ce n’est vraiment pas viable, nous disons tout simplement non en expliquant le pourquoi.

Enfin, les demandes sont rarement en adéquation avec le budget et avec les besoins (demandes != besoins). C’est notre rôle d’expliquer les contraintes, les enjeux, de ressortir les objectifs et d’aider le client à définir des budgets.

Ce travail de conseil est un travail passionnant et c’est vraiment à l’opposé de « J’ai suivi votre cahier des charges, si ça ne fonctionne pas, c’est votre faute »

Idem bien sûr quand on consulte des agences : les devis vont du simple au double, on t’explique que tel ou tel truc c’est « 3 jours de dev », mais on te dirait « 8 jours de dev » de toute façon ce serait pareil, quand tu ne connais pas le domaine c’est très compliqué de savoir ce qui est raisonnable ou pas.
Je vis ça aujourd’hui avec l’agence qui a conçu mon site. A la moindre modif on m’annonce 2 jours de dev, et quand je demande autour de moi je trouve toujours quelqu’un pour me dire que c’est l’affaire d’une heure de taf. Pierpoljak connait toujours un dev freelance qui fait du super boulot pas cher, etc.
Sauf qu’à l’usage le freelance en question a des domaines où il est super bon et d’autres où il rame, il bosse de minuit à 3h00 après ses cours ou après son boulot principal en agence, il ne tient pas les délais parce qu’il est charette, quand il ne te plante pas ton truc en plein milieu sans l’avoir fini. Tu peux te retrouver la queue entre les pattes en agence avec ton sac de noeuds sous le bras qui t’a déjà coûté 5000 et qui est bon à jeter.
Donc franchement, tout ça est bien souvent une source de très grande frustration pour moi. Un crash course pour dirigeant me serait bien utile pour essayer de comprendre un peu ce qui occasionne 3 jours de dév et ce qui prend deux minutes à faire.

très bon article. Je suis « côté ingénierie » (et je n’utilise pas le mot agence) et il est fréquent de voir des jeunes startup (mais pas que…) complètement démunies face à des projets qui ont été foirés par des incompétents sans scrupules, avec des livrables inexploitables, des « je ne m’attendais pas à ca » et des « ca ne sortira jamais ».

De mon point de vue, plusieurs facteurs mènent à cela : une mauvaise définition du minimum vital, une mauvaise coordination entre les phases de développement et les périodes de rentrées de chiffre d’affaire et une demande initiale faussée : « je veux un devis pour cette idée ». Comme tous les mauvais facteurs, ils n’apportent jamais le recommandé.

Cela mène inévitablement à des agences sans scrupules qui estiment à la louche (tete du client, prévision de déblocage de budgets), sans maquettes, sans étude, sans spec technique, à partir du besoin exprimé… parcequ’ils font des devis à la pelle en espérant se trouver le bon pigeon et s’en sortir tant bien que mal. De plus, beaucoup d’agences web (pas toutes, hein les mecs de onemorething sont bons coucou Jerem) n’ont pas du tout les compétences pour monter un business web… cette année nous avons vu deux applications métier ruinées écrites sous WordPress juste parceque *ces* agences ne connaissent rien d’autre. (NB on n’a rien contre WordPress, il faut juste pas l’utiliser pour tout et n’importe quoi, et certainement pas pour une application de gestion du personnel, par exemple…).

Établir le budget d’un projet, c’est déjà recentrer le besoin, choisir la méthode de gestion de projet adaptée, phaser, établir les choix techniques, maquetter, détailler et tout écrire. Ensuite seulement il sera possible de déterminer des coûts rentables de solution, trouver des arrangements, prioriser et établir les devis.
Seulement ce travail a un coût, qui n’est pas négligeable.

OK, beaucoup de clients vous disent « oui mais les autres ils ne m’ont pas fait payer le devis »… soit on les éduque un peu, soit on laisse tomber.

Dans mon cas, plusieurs cas de figure : sur des projets pouvant être lean, tant mieux. Minimum vital, phases courtes, prototypage, démerdage mais des KPI et un focus sur le ROI rapide pour financer la suite. Par contre transparence, savoir dire non, ne pas rêver sont de rigueur.

Pour les projets non-lean (parceque pas toujours possible ou trop techniques), nous procédons comme un cabinet d’architecture : découper le projet, prioriser, faire les plans, trouver les matériaux, contacter les prestataires et tiers, s’assurer des réglementations, etc. Du coup, nous facturons comme un architecte, au temps d’étude passé. A cette issue, le client a un dossier clair, présentable au financement, et libre à lui de continuer ou pas avec nous sur la réalisation, de faire jouer les devis comparatifs par lots, car là c’est possible.

Bref c’était un peu long, désolé, mais je suis effectivement très sensible à ce genre de sujet. J’espère que cela donnera de bonnes idées pour 2015 et suis à l’écoute de vos réactions !

Ce qui reste vrai c’est que WordPress et consors permettent à un porteur de projet de valider un concept auprès de premiers utilisateurs/clients avant de s’adresser à une agence, ou même à un associé technique qui sera difficile à intéresser avant.

« WordPress est bien pour un blog ou un site vitrine mais rien de plus (je parle d’un point de vue professionnel, pour bidouiller dans son coin, c’est une autre histoire). »

En tant que développeur web, je trouve cette remarque hâtive et datée. WordPress a beaucoup évolué, et si des problèmes de scalabilité (quelqu’un aurait un équivalent français ?) peuvent exister, les projets gérables sur WP sont bien plus variés que les simples blogs/sites vitrines…

bonjours, j’ai un projet, mais pas le budget, je propose de vous donner XX% des parts de la boite, en échange d’un dev de XX mois.

A date, j’ai toujours refusé, et aucun des projets que j’ai refusé n’a aboutit à une start up a succès

Ca m’a bien fait rire pour le ton car je suis dans un état d esprit un peu similaire

Mais tout de même dire que les agences font payer 25k€ un site tout buggé de partout.. comment dire.. je dis pas que ca peut pas arriver, mais quand c est le cas, c est que l agence est déjà grave en perte (le projet géré de manière *agile* car des retours chaotique du client a été modifié 35 fois, générant son lot de bordel et dev inutiles..)

Pour ma part (agence) j’essaye maintenant de ne prendre que des clients de confiance qui comprennent les problématique et acceptent de partir sur un dev agile en payant au temps passé.
Ça implique d’avoir confiance mutuelle, mais je préfère avoir moins de clients et éviter de me casser les dents sur les projets mal ficelés.

Le problème principal de startups, c’est qu’elles ont une (bonne) idée de produit mais que le temps de la réaliser, les idées avancent, le client reçoit des conseils de ses proches, la technologie évolue et le périmètre du projet n’est plus le même. C’est impossible à gérer avec les méthodes en V, ou le périmètre est le cahier des charges et tout ce qui change est « hors scope », donc refacturable. on est plus en 2000.

On bosse essentiellement avec la méthode Lean startup. On part d’un vrai MVP (minimum viable product), on test, on adapte… Un projet (site web, appli mobile, etc.) change beaucoup trop vite pour se fixer sur un CDC. Ca implique plus de dispos et d’interactions avec le client (que vous valoriserez) mais au moins on évite les méthodes en « boite noire » ou le client ne voit son produit qu’à la fin et se retrouve avec un devis qui liste toutes les évolutions / adaptations qu’il souhaite.

Mais ça veut aussi dire qu’il faut être transparent et honnête (ce qui n’est pas opposé à commercial ou rentable) et savoir dire NON au client lorsque certains éléments du projets sont de trop (mauvaises idées, fonctionnalités overkill, ou trop de fonctionnalités qui n’ont pas leurs places dans le MVP). On réduit le périmètre, ça coute moins cher au client, mais il sera plus rassuré et satisfait du travail et aura toujours le budget pour rajouter des nouvelles fonctionnalités ou pivoter (release fast, release often!). Mettez-vous à sa place, mais pas que dans le discours, pendant le projet. Si vous étiez un utilisateur de l’application, utiliserez-vous cette fonctionnalité ? Sachez dire non, c’est vous l’expert. Si le client est content de son expérience, il restera avec vous.

Bon, je me suis laissé aller, c’est vendredi soir, allons boire des bières !