Il sera ici question d’Atelier web soit sous traitant produisant pour des agences web, soit développant directement pour le client final.
La grande difficulté avec le plupart des clients potentiels est qu’ils ne sont pas disposés à passer beaucoup de temps à expliquer au représentant de l’atelier web leurs besoins… avant de savoir si le prix du développement de l’atelier web leur conviendra.
Mais sans avoir une idée claire du besoin, Il est impossible de donner un prix fiable pour le développement.
Dans cette situation, les acheteurs sont en position de force, et ils utilisent consciemment ou non cette situation pour pousser l’atelier web à prendre des engagements financier… qui pourraient s’avérer progressivement non rentables une fois le besoin client complètement mis à jour.
Quel sont donc les options possibles ?
L’atelier peut standardiser, mais il y a des risques
La première réponse possible pour qu’un atelier web évite les dérives est de standardiser au maximum les offres, de manière à cadrer le client.
Le problème est que l’atelier va alors se retrouver en concurrence avec des concurrents qui vendent des sites simples, standardisés… et à prix cassés…
L’atelier web doit donc impérativement trouver des moyens de garder de la valeur ajoutée, qui lui permet de vendre à des prix acceptable, et cette valeur ajoutée passe largement par la capacité à proposer du développement et du design sur mesure.
Simplement, vu la réduction des marges, un atelier ne peut plus se permettre des projets vendus sur une cotation initiale « au jugé », puis une première inflation des spécification dans la cahier des charges final, et ensuite diverses demandes que les différente « décideurs » de l’entreprise cliente rajoutent au fur et à mesure… sans avoir la possibilité de revoir les prix en proportion des ajouts.
L’atelier peut beaucoup formaliser le travail
Ici il est question d’abord de bien faire valider le cahier des charges final, si nécessaire en demandant à ce stade une rallonge pour ce qui est apparu depuis la cotation initiale.
Ensuite si des demandes significatives (parfois signalées à tort comme bugs…) apparaissent en cours de projet, il faudrait à chaque fois fournir une mini cotation pour chaque nouveauté, ce qui risque de vampiriser la ressource qu’est chef de projet, qui a généralement autre chose de plus productif à faire.
La formalisation implique une vraie lourdeur. Il n’est pas facile de faire et refaire à chaque fois des comparaisons entre les différentes versions des devis et cahiers des charge pour voir jusqu’à quel point la dernière demande est nouvelle.
Bien souvent, quand les chefs de projets doivent choisir, ils préfèrent donner la priorité au projet, pour le faire avancer et satisfaire le client, et du coup les calculs et re-calculs de coûts (la partie plus administrative) sont reportés, parfois jusqu’à la fin du projet.
Le problème des estimations au forfait (prix fixe) est d’autant plus aigu que souvent le ou les décideurs commencent à vraiment savoir ce qu’ils veulent… quand ils voient un résultat concret. Or souvent, le résultat obtenu est cohérent avec la demande initiale, mais à partir du moment ou le client visualise quelque chose, il arrive à formuler, par réaction, ce qu’il souhaiterait vraiment, qui souvent est assez différent de la première version présentée.
Pourtant, même si la dérive du volume de travail est assez facilement perceptible par les clients finaux, beaucoup restent soit enfermés dans la logique du prix fixe comme pour les produits de série disponibles dans les rayons d’un supermarchés ou d’une boutique en ligne, soit restent enfermés dans un budget validé au départ et qui ne peut, quels que soient les changement intervenus, être revu.
Autant dans le BTP par exemple il est connu que les marges se font sur les demandes additionnelles quand le projet est déjà en cours d’exécution, autant quand il est question de développer un site ou une application web sur mesure, les rallonges de budget peuvent être très difficiles à obtenir, même quand on a des arguments « en béton »…
L’atelier peut surtout devenir agile sur tous les plans
L’idée est que l’atelier web arrive à déployer de la pédagogie pour devenir agile pas seulement au niveau des spécifications, mais aussi, tout autant, de la facturation.
L’objectif du client doit être de ne pas se fâcher avec son atelier web avant la phase de maintenance évolution, sous peine de rendre plus complexe, aléatoire et coûteuse la phase en question.
Le système agile fonctionne sur la base d’une série de sprints de développements successifs. On prévoit pour chaque sprint les choses qui doivent être réalisées et le délai.
L’idée est que les développeurs puissent être affectés aux taches prioritaires, même si l’ajout de certaines taches à la liste des taches à réaliser est récente.
Or si le volume de travail augmente, cela implique soit d’augmenter le budget, soit de renoncer à une partie des taches souhaitées, au moins à court terme, tant que la série de « sprints agiles » prévus ne sera pas terminée.
En fait il faut avoir la capacité à estimer, à la fin d’un ou d’une série de sprints, le volume de travail restant, et donc le budget nécessaire pour l’étape suivante.
Cela présuppose de sortir d’une vision très « contrôle de gestion », donc très lourde et coûteuse en ressources de gestion de projet, de certains clients, et plus généralement, cela nécessite que les deux parties se fassent confiance.
Mais ceci est loin d’être acquis si le client en possède pas en interne une compétence technique ou au moins projet web, pour pouvoir évaluer si les estimations de temps restant de la part de l’atelier web, donc de coût associé, sont réalistes / plausibles.
Dans un tel cas, le recours ponctuel à un tiers de confiance, neutre, peut apporter un plus.
Le fait de pouvoir présenter des références de l’atelier web, tout spécialement sur des projets réalisés en agile, est aussi un vrai plus pour rassurer l’acheteur de prestation web.
Dans tout les cas de figure, les choses ne sont jamais très faciles, dès lors qu’il est question du coût d’un développement.
Enfin, dans certains cas, il faut aussi se rendre à l’évidence ; certains projets ne sont tout simplement pas rentables, le budget nécessaire dépasse les possibilité de l’acheteur et il faut avoir le courage, après avoir fait tout ce qui était possible, à commencer par un gros travail de pédagogie, d’arrêter les frais. Le plus tôt est souvent le mieux.
En conclusion, mises devant une alternative, les entreprises acheteuses qui refusent les aléas de la logique agile doivent ouvrir encore plus leur portes, à tous les niveaux, aux CP des agences /ateliers web pour permettre une validation claire du cahier des charges au nom de toute l’entreprise, sinon le travail ne peut pas démarrer, quel que soit le degré d’urgence du projet.
Si le travail de pédagogie n’est pas fait au niveau de tous les décideurs du client, il y a même un risque de double peine pour l’atelier web, à savoir que le client qui lui a demande en cours de route beaucoup plus de travail, l’attaquera en plus pour… ne pas avoir respecte les délais, alors même que le fait de rajouter du travail en plus est une cause logique pour rallonger proportionnellement les délais. Parfois même les clients n’ont pas envoyé tous les contenus le jour de la date de livraison (initialement) prévue du site, ce qui ne les empêchera pas de s’indigner du fait que le site ne sont pas terminé à la date en question…
D’où l’intérêt de prendre très au sérieux l’étape contractuelle au départ…