Si vous avez déjà vécu un projet de développement raté, cette page est pour vous.
Beaucoup de dirigeants que nous rencontrons ont déjà payé pour un système qui n’a jamais servi. Ils ne cherchent pas à savoir si nous sommes bons. Ils cherchent à savoir pourquoi ce serait différent cette fois-ci. Voici la réponse, sans détour.
Trois causes, et aucune n’est technique.
-
Cause 01
Un cahier de charges écrit sans regarder le travail réel
Quelqu’un a demandé aux gestionnaires comment le travail se fait. Ils ont décrit la procédure. Mais sur le plancher, la procédure a été contournée il y a trois ans parce qu’elle ne fonctionnait pas — et personne ne l’a écrit nulle part. Le système livré automatise donc un processus qui n’existe plus. Il est conforme au document et inutilisable en pratique.
-
Cause 02
Une facturation à l’heure
Elle transfère tout le risque sur vous. Un dépassement devient une facture supplémentaire plutôt qu’un problème du fournisseur, et le fournisseur n’a aucun intérêt à finir vite. Ce n’est pas une question de malhonnêteté, c’est une question d’incitatif.
-
Cause 03
Trois intermédiaires entre vous et celui qui code
Vous expliquez au chargé de compte, qui rédige pour le chef de projet, qui découpe pour l’équipe, qui exécute sans avoir jamais vu votre entrepôt. Chaque transmission perd un détail — et les détails sont exactement ce qui fait qu’un outil de gestion sert ou ne sert pas.
Un mauvais incitatif finit toujours par gagner.
Une réponse par cause, et rien de plus compliqué que ça.
-
01 — Comprendre
Nous regardons le travail se faire
Avant d’écrire quoi que ce soit, nous passons du temps là où le travail se fait, avec les gens qui le font. Nous notons les contournements plutôt que de les corriger : ce sont eux qui révèlent où le processus officiel ne tient pas. C’est l’étape que les autres facturent le moins.
-
02 — Cadrer
Un prix fixe, et une liste de ce que nous ne construirons pas
La portée est écrite dans les deux sens. Ce qui est dedans, ce qui est dehors, et pourquoi. Le prix est fixe : si nous avons mal estimé, c’est notre problème. Vous savez ce que ça coûte avant de commencer.
-
03 — Construire
Quelque chose d’utilisable chaque semaine
Pas une maquette, pas un rapport d’avancement : une partie du système qui fonctionne, que vous pouvez ouvrir et essayer. Une mauvaise direction se découvre ainsi en sept jours plutôt qu’à la livraison finale.
-
04 — Rester
La même personne, après la livraison
Vos opérations changent, votre outil doit suivre. Il n’y a pas de transfert vers une équipe de soutien qui ne connaît pas le dossier : c’est la personne qui l’a construit qui répond.
Ce qu’un fournisseur refuse en dit plus long que ce qu’il promet.
-
→
Nous ne facturons pas à l’heure. Le risque d’estimation est le nôtre, pas le vôtre.
-
→
Nous ne construisons pas ce qui existe déjà. Si un logiciel du marché fait le travail pour le tiers du prix, nous vous le dirons — même si ça nous coûte le mandat.
-
→
Nous ne gardons pas votre système en otage. Le code, les données et les accès vous appartiennent. Vous pouvez partir chez un autre fournisseur sans rien reconstruire.
-
→
Nous ne prenons pas un mandat dont nous ne comprenons pas le métier. Un système bâti sur une compréhension approximative coûte plus cher qu’un refus poli.
La première conversation ne coûte rien.
Décrivez votre situation en quelques lignes. Nous vous répondons avec une première lecture du problème — y compris, s’il y a lieu, que ce n’est pas pour nous.