Vous allez lancer un projet custom. Vous avez une idée. Mais vous savez que ça peut aussi mal tourner. Voici les 7 pièges que vous verrez forcément.
Chez Leando, on parle à 2-3 dirigeants par semaine qui veulent lancer un projet custom. Et on voit la même chose tout le temps : ils lancent avec enthousiasme, mais après 4 mois ils ont dépassé budget et délai. Pourquoi?
Ce n'est jamais parce que le dev est mauvais. C'est parce qu'on a oublié de poser les bonnes questions avant de coder. On oublie d'impliquer les gens qui vont vraiment l'utiliser. On vise une version parfaite dès le jour 1.
Voici les 7 erreurs que nous voyons. Si tu les vois arriver chez toi, c'est qu'il est temps de freiner et de rectifier.
"Le dev peut commencer demain"
⚠️ Pourquoi c'est une erreur
Tu laisses un dev coder avant de clarifier ce que tu veux vraiment. Il code. Tu vois le résultat à la fin. Et là: "Attends, c'est pas ça..."
Le symptôme
Le dev a codé 80% du projet. Tu lui dis "c'est pas bon". Il reprend. Ça coûte 2x plus cher et prend 2x plus longtemps.
✓ La vraie approche
AVANT le code: clarité. Ateliers de 2 jours. Wireframes. Mock-ups. Dessins sur tableau blanc. Que tout le monde voit et valide avant une seule ligne.
"On va faire une app" au lieu de "Notre comptabilité est lente"
⚠️ Pourquoi c'est une erreur
Tu as une solution en tête ("une app web"). Mais tu as pas vraiment étudié le problème. Peut-être que t'as pas besoin d'app. Peut-être qu'une simple intégration Excel suffit. Peut-être qu'il manque une étape avant.
Le symptôme
Tu dis "On va faire une app pour la prise de commande". Mais le vrai problème c'était "Nos commerciaux mettent 3h pour saisir une commande" (manque de formation, mauvais process).
✓ La vraie approche
Audit d'abord. "Pourquoi c'est lent?" "Qu'est-ce qu'on peut améliorer sans coder?" "Où est le vrai boulot?" Après seulement, la solution technique devient évidente.
"Attendez jour 30 pour voir le résultat"
⚠️ Pourquoi c'est une erreur
T'impliquerais les gens qui vont vraiment l'utiliser APRÈS que la dev soit 80% faite. Ils te disent "Oh non, c'est pas ça..." Tu dois refaire. Coûteux. Déprimant.
Le symptôme
"Le dev était sympa mais il a pas compris notre métier." Oui, parce qu'on lui a jamais demandé son avis jusqu'à la fin.
✓ La vraie approche
Les futurs utilisateurs au jour 1. Wireframes sur tableau blanc. "C'est ça?" Feedback immédiat. Tests early & souvent. Pas d'attente de 30 jours.
"Qui cares des intégrations, on les fera après"
⚠️ Pourquoi c'est une erreur
Tu dois nourrir ce logiciel avec des données (CRM, ERP, Excel, bases de données existantes). Oublie les intégrations = les gens resaisissent à la main. C'est le contraire d'une automatisation.
Le symptôme
"On a le logiciel, mais on doit toujours taper les données partout." C'est qu'on a jamais pensé aux ponts de données.
✓ La vraie approche
Jour 1: "Avec quoi ce logiciel va parler?" CRM? ERP? Comptabilité? Qui sont mes sources de données? (Jour 1, pas jour 30.)
"On la fait bien. À la fin. Complète."
⚠️ Pourquoi c'est une erreur
Tu vises la perfection dès le jour 1. Feature A. Feature B. Feature C. Feature D. Le scope devient infini. Délai: 12 mois. Budget: x3. Personne n'est heureux.
Le symptôme
"Ça prend combien de temps?" "Hmm, compliqué à dire. Il y a tellement de features..."
✓ La vraie approche
MVP (Minimum Viable Product). Phase 1: les 3 trucs essentiels. Livrer vite. Les gens l'utilisent. Feedback. Puis phase 2. Itération >perfection d'abord.
"On la lance et voilà"
⚠️ Pourquoi c'est une erreur
Tu livres le logiciel. Silence. Personne sait vraiment si les gens l'utilisent. Personne sait où ça frotte. Personne sait si ça marche. C'est l'inverse d'une automatisation.
Le symptôme
"Ça marche?" "Oui, je pense..." (Personne ne sait vraiment.)
✓ La vraie approche
Jour 1: définir ce que "marche" veut dire. "Combien de personnes l'utilisent?" "Combien d'heure/j ça sauve?" Tracker ça. Ajuster.
"On va le faire nous-mêmes"
⚠️ Pourquoi c'est une erreur
T'es tout seul face au problème. T'as pas de perspective extérieure. T'oublies des questions. T'as pas le retour de quelqu'un qui a vu 100 projets avant toi. Tunnel vision.
Le symptôme
"Comment on n'a pas vu ça?" "Pourquoi on a pas posé cette question?" Trop tard, on est 6 mois dedans.
✓ La vraie approche
Un partenaire technique (internal ou external) qui a vu ça avant. Qui pose les questions qu'on oublie. Qui dit "attends, on a oublié ça". Ça vaut chaque euro investi.
Questions qu'on nous pose
Toujours par l'analyse. Code = exécution. Analyse = compréhension. Si tu fonces dans le code sans clarifier le problème, tu vas refaire 2-3 fois. Passe 2 semaines à auditer, discuter, wireframer. Ça sauve 4 mois après.
On s'appelle avant que tu lances. Leando audite votre approche, identifie les pièges et dessine une roadmap qui marche.
Parlons de ton projet