Régulièrement, je suis sollicité par des prospects / clients qui souhaitent réaliser le MVP de leurs rêves mais qui ont des moyens limités. Ils souhaitent faire une application qui leur permet de démarrer leur activité mais n’ont « que » quelques milliers d’euros pour la faire. Ils font appel à des freelances pensant qu’ils seront flexibles, compétents et moins chers… Ils pensent également qu’ils vont pouvoir travailler à un prix fixé à l’avance : le freelance n’aura qu’à être bon pour rentrer dans ses coûts.
Bref, ils font le pari que pour 2500 € HT « tout compris », ils auront l’application / MVP dont ils ont besoin et laissent le soin au freelance finalement d’assurer le risque de dérive du projet en cours de route.
Parfois, c’est le freelance qui propose cette approche afin de gagner un projet : cette pratique se retrouve sur nombre de plateformes de freelances avec des systèmes d’enchères qui sont finalement « inversées », le moins disant remportant la mise. Il ne faut pas non plus aller très loin pour retrouver cette pratique sur le marché de manière plus large : SSII ou agence digitale faisant des projets au forfait en espérant se rattraper sur les avenants, (petit ou pas) éditeur cassant les prix de la licence pour se refaire sur le projet d’intégration chez le client, etc.
Selon moi, cette pratique est suicidaire et dé-responsabilisante pour le client et pour la personne réalisant le projet : freelance ou société établie. Au mieux, l’une des parties va tirer partie de la faiblesse de l’autre, au pire, les deux parties vont être frustrées : le client n’aura pas tout le périmètre (ou aura l’impression que chaque modification lui coûte un bras) et le prestataire – j’ai lâché le mot – aura l’impression de se saigner chaque jour et bâclera le travail pour terminer, en prenant des raccourcis sur la qualité et les fonctionnalités (alors que c’est au client de décider le niveau de qualité et les fonctionnalités souhaitées).
Il y a un débat régulièrement sur le sujet entre « forfait » (obligation de résultats) et « régie » (obligation de moyens).
Au fait, c’est quoi un projet ?
C’est une « aventure avec un A » avec un début et une fin, qu’on espère heureuse et dont les caractéristiques sont complètement différentes d’une autre « aventure avec un A ».
Cela peut sembler « évident » mais c’est souvent mal compris.
La différence entre projet et opérations
Si, chez vous, chaque projet est identique dans son contenu, ce n’est pas un projet mais ce sont des « opérations » : exemple, fabriquer une voiture en série est une opération répétitive qui déroule systématiquement les mêmes étapes pour fabriquer toujours exactement la même voiture (ou en tout cas, assembler des pièces & options pré-disponibles)
Projets ≠ Opérations
Autre différence : les opérations sont des actions mesurables, sur lesquelles il est facile d’avoir des KPIs (exemple : le nombre d’appel à la Hotline, la durée de chaque appel, la satisfaction client, la solvabilité de tel client, le ratio # appels par # utilisateurs, etc, etc.) et pour lesquelles il faut entraîner les équipes « à la recherche du beau geste » (un peu comme un joueur de tennis qui répète pendant des années le même geste afin d’améliorer sa proprioception).
Donc réussir un projet, ce ne sont pas les mêmes compétences et les mêmes manières de réussir que d’assurer les opérations. C’est la différence entre la phase de construction d’un logiciel « BUILD » (c’est un projet) et la phase d’exploitation de ce logiciel « RUN » (ce sont des opérations).
Même si les techniques utilisées pour mesurer, organiser les opérations peuvent s’appliquer pour améliorer la performance, le suivi et l’organisation d’un projet (je pense en particulier aux techniques issues de l’industrie automobile comme le Kanban), il ne faut pas perdre de vue cette différence fondamentale. C’est parfois ce qui rend « chèvre » des personnes issues des opérations dans l’entreprise (service support, production, etc) quand elles « regardent » ce que fait la « R&D », cœur même des projets dans toute entreprise (quelle que soit la manière dont elle le nomme : équipe de dev, « les développeurs », l’équipe produit, la direction technique, etc).
Vite fait, pas cher et de qualité
C’est finalement ce que les clients, gros ou petits, attendent d’un « projet informatique ». Certains sont plus mâtures que d’autres sur le sujet bien sûr et cela peut sembler caricatural.
Ceci étant, du fait de cet incompréhension ou de ce lieu commun, souvent, se retrouvent autour de la table les acteurs d’un projet en crise, qui ne savent pas comment « sortir par le haut », pris, qui plus est, dans le carcan d’un contrat ficelé par des personnes qui ne participent pas au projet.
Vite fait, pas cher et de qualité : cela n’existe pas, un point c’est tout.
Une dose de GBS (« Gros Bon Sens » pour reprendre l’expression d’une personne avec qui j’ai collaboré dans le passé), du bon sens « paysan » ou le niveau de réflexion enfant de cinq ans : c’est pourtant ce qui échappe à beaucoup de personnes, tout le monde, pariant sur un avenir meilleur & acceptant d’être dupe.
A propos de l’auteur : Benoît Fillon
Lisez aussi :
Freelances : arrêtons de les tondre à coup de commissions !
Freelancing, outsourcing, salariat : Comment accéder à la ressource digitale