Développement : comment j’ai appris à ne plus m’en faire et à aimer la régie

Depuis mes débuts dans le monde informatique, j’ai eu l’occasion de suivre et réaliser de nombreux projets. Ceux-ci étaient en grande majorité au forfait, c’est à dire facturé à un prix fixe basé sur un cahier des charges.

Le forfait

Le système est ainsi fait : les clients expriment un besoin — généralement sous la forme d’un appel d’offres — auquel les entreprises compétentes répondent avec un devis.

Pour ce faire, chacune fait suivre l’expression de besoin au personnel technique pour obtenir une estimation du temps que prendra ce projet. Cette estimation est “challengée” par l’équipe commerciale afin de la diminuer au maximum, car évidemment il ne faut pas oublier que plusieurs entreprises sont susceptibles d’être en concurrence pour décrocher le contrat. Un savant calcul est alors effectué en prenant des critères comme le coût journalier, le nombre de personnes affectées au projet et différentes marges de sécurité pour obtenir le tarif final. Ce processus est un énorme vecteur de stress pour les personnes impliqués, bien que le travail n’ai pas encore commencé…

Estimer le temps de réalisation d’un projet informatique est loin d’être une science exacte. Sa précision est inversement proportionnelle au nombre de fonctionnalités. 
En clair, plus la tâche est grande, plus l’incertitude de temps augmente.

L’incertitude augmentant avec la complexité

Un vrai casse-tête pour les entreprises qui n’ont alors d’autre choix que d’ajouter une marge de sécurité afin de limiter les risques.

Au final, le client sélectionne souvent le prestataire avec la proposition la moins chère. Le résultat est par invariablement l’un des suivants :

  • Le prestataire a planté son estimation et finit le projet à perte, auquel cas il devra bâcler la fin du travail pour limiter la casse.
  • L’estimation est tombée juste — ce qui n’est pas si courant— et le projet peut donc être considéré comme un succès.
  • Le projet est fini en avance et le prestataire augmente donc sa marge, même si le client aurait bien utilisé celle-ci pour d’autres éléments de son business plan.

Indépendamment de ces résultats, il ne faut pas oublier que “challenger” l’équipe technique en début de projet ne se fait pas sans prendre des raccourcis. Ces mêmes raccourcis se transforment immanquablement en dette technique, au détriment du client et de l’éventuel prestataire qui reprendra le projet par la suite.

Le client est donc bien souvent perdant en récupérant un projet fait à la va-vite, potentiellement bâclé et/ou surpayé.

La régie

La régie consiste tout simplement à facturer au temps passé. Avec ce format, le prestataire peut toujours fournir une estimation au client, mais celle-ci reste informelle.

Fonctionner ainsi présente plusieurs avantages.

  • Côté technique, le prestataire n’a aucun intérêt à prendre des raccourcis ou à bâcler le travail, car le client peut alors arrêter la collaboration du jour au lendemain.
  • Si le projet se termine plus rapidement que prévu, le client comme le prestataire rentrent dans leurs frais.
  • Dans le cas contraire, le prestataire est plus facilement capable d’expliquer les raisons du retard, chose qui ne serait pas possible en avance de phase.

Avec ce système, le client est toujours gagnant, d’autant qu’il a aussi la possibilité d’arrêter le projet à tout moment dans le cas où le prestataire ne n’est pas sérieux ou ne répond pas à ses attentes, et donc de limiter la casse. 
Au niveau du prestataire, plus de possibilité de “marge bonus”, mais la garantie de toujours rentrer dans ses frais tout en limitant la pression sur l’équipe technique.

C’est du gagnant-gagnant, avec moins de stress à la clé.

La stratégie de l’échec

Alors pourquoi la grande majorité des projet informatiques sont-ils toujours effectués au forfait? 
Il y a probablement plusieurs réponses. Le principe des appels d’offres, qui pour les entreprises sont un moyen — même s’il reste virtuel — de se projeter sur les coûts. Peut-être aussi le manque de confiance, la peur que le prestataire fasse “traîner” le projet aux frais du client.
Le besoin aussi d’une communication plus régulière qui n’est pas toujours réalisable dans certains cas.

Cependant, en ce qui me concerne, je ne regrette pas le choix de m’être tourné presque exclusivement vers les projets au temps passé depuis que j’ai lancé ma propre activité. 
Cela m’a permis d’aborder l’entrepreneuriat avec moins d’insécurités, mais aussi et surtout de créer des relations de confiance durable avec mes clients.

Si vous souhaitez vous aussi faire la transition avec vos clients, n’hésitez pas à leur relayer cet article, le meilleur choix est toujours celui fait en toute connaissance de cause !


Alexis Creuzot est développeur et co-fondateur de Monoqle, une entreprise spécialisée en développement iOS natif.