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

Alexis Creuzot
Feb 24, 2016 · 3 min read

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.

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, elles font suivre le cahier des charge au personnel technique pour obtenir une estimation du temps. 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 souvent vecteur de stress pour les personnes impliqués. Pourtant, le travail n’a 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 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, quelque soit le prestataire sélectionné par le client, le résultat est par forcément l’un des suivants :

  • Le prestataire a sous-estimé la charge et finit le projet à perte, auquel cas il devra souvent bâcler la fin du travail pour limiter la casse.
  • L’estimation est tombée juste — ce qui est rare— et le projet peut donc être considéré comme un succès.
  • Le projet est fini en avance, le prestataire augmente donc sa marge. Cependant le client aurait probablement bien aimé utiliser 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.
  • 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. Il a par-ailleurs la possibilité d’arrêter le projet à tout moment si le prestataire ne répond plus à ses attentes. Au niveau du prestataire, plus de possibilité de “marge bonus”, mais cependant la garantie de toujours rentrer dans ses frais.

C’est du gagnant-gagnant avec — cerise sur le gâteau — 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 plusieurs raisons :

  • Les appels d’offres restent pour les entreprises un moyen — bien que virtuel — de se projeter sur les coûts.
  • Le manque de confiance et la peur que le prestataire fasse “traîner” le projet aux frais du client.
  • Le besoin aussi d’une communication plus régulière dans le cadre de la régie, qui n’est pas toujours réalisable.

En ce qui me concerne, je ne regrette pas le choix de m’être tourné presque exclusivement vers du temps passé depuis que j’ai lancé mon 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 (et donc de travail) durable avec mes clients.

Si vous souhaitez vous aussi faire la transition, n’hésitez pas à 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 mobile.

6

6 claps
Alexis Creuzot

Written by

 Developer & Co-founder of Monoqle