A qui s’adresse ce guide ?

Nous pouvons identifier a minima trois « personae » pouvant être intéressées par ce guide. 

• L’héritier : n’assumant pas la fortune léguée par son grand-oncle, l’héritier souhaite rapidement et efficacement dilapider son argent, dans un projet sans avenir. 

• L’influenceur LinkedIn : en quête de contenu à succès, l’influenceur pourra se servir de cet échec monumental pour capter du like sur un post ayant pour titre: « Il n’y a pas d’échec, que des leçons » ou bien « Je ne rate jamais, j’apprends ». Idéalement, il est conseillé de combiner influenceur Linkedin et héritier.

• Le futur fermier : avec un poste de DSI, de responsable projet ou marketing dans une belle entreprise, il/elle souhaite se reconvertir dans la production de cidre bio en Aveyron. L’échec monumental du projet digital qu’il pilote sera le point de départ de cette nouvelle vie.

Les 13 astuces

1. « Comme Uber, mais »

Point de départ essentiel d’un projet raté, le concept. 

Là où un bon concept ne permettra pas toujours de réussir, un mauvais concept sera à tous les coups gagnant pour foirer son projet. C’est donc un point essentiel dans la structuration de votre échec à venir.

Un mauvais concept peut prendre plusieurs formes :

• Il ne répond à aucun besoin, ou presque.
• Le concept démarre par « Je souhaite faire comme Uber, mais ». Le « Uber » pouvant au choix être remplacé par « Facebook », « Tinder », « Leboncoin » et j’en passe. L’idée est de copier un concept existant, en moins bien.
• Le concept suit la formule dite de l’inutilité matérialisée par la formule suivante : 

(Valeur générée) / (Effort généré) < 1

 

2. Le millefeuille

Le théorème du millefeuille s’applique aussi bien sur une base de mauvais concept que de bon concept. Sur la base d’un mauvais concept, il servira d’accélérateur d’échec. Sur la base d’un bon concept, cette stratégie fera office de sabotage efficace.

Le principe du millefeuille est d’ajouter quantité de fonctionnalités, utiles ou non, sur la base du concept initial. 

L’objectif donné, pour le porteur de projet, est de se donner l’illusion que l’accumulation crée la valeur. Le résultat, pour les utilisateurs finaux, sera à coup sûr de se retrouver face à une usine à gaz, impossible à prendre en main, et où le potentiel concept de base initial, pertinent, serait noyé dans 90% de fonctions inutiles.

Pour savoir si vous avez un « bon millefeuille », essayez de résumer votre projet en moins de 10 secondes. Si vous y arrivez, il manque sans doute quelques fonctionnalités à rajouter. 

Pour vous aider, voici quelques idées pouvant être facilement ajoutées :

• De la gamification 
• Une connexion à Salesforce
• Une messagerie instantanée 
• De la réalité augmentée
• Une fonctionnalité d’import flexible
• La possibilité d’ajouter des gens en « amis »
• Un blog

 

 

3. Le théorème de la mamie

Le théorème de la mamie, qui fonctionne aussi avec les tontons, parents, amis proches, conjoints, collègues de bureau etc… se résumerait ainsi:

 « Le meilleur moyen d’obtenir un avis positif sur son concept est de le présenter à sa mamie »

En effet, dans 99,85% des cas, le retour sera positif avec au choix :

• « C’est une super idée, fonce ! »
• « Ah oui c’est vraiment pas mal »
• « Tiens moi au courant quand cela sort, je serai la première à l’utiliser »
• « Je suis fière de toi »

 

L’avantage de ce théorème est qu’il fonctionne aussi bien sur la base d’un mauvais concept, que d’un bon concept. Il vous permettra de charger votre confiance, et d’occulter tous les éventuels signaux négatifs externes.

•  

4. L’ambition sans les moyens

Un projet digital, c’est un coût initial, le « build », et des coûts récurrents, le « run ». 

Idéalement, il est préférable de se positionner directement sur un concept, dont le coût de build de la version 1 dépasse déjà très largement sa capacité d’investissement. 

C’est en général un bon point de départ pour effectuer les mauvais choix en termes de technologies (voir « La stack ») et d’équipe (voir « Les misfits »). 

Néanmoins, ne plus avoir de budget pour le « Run » peut être suffisant pour aller dans le mur, même si les parties de conception et développement ont été correctement réalisées.

Plus de budget pour le « Run », c’est s’assurer de plusieurs erreurs fatales :

• Aucun moyen d’acquisition et de rétention de ses utilisateurs via des leviers marketings internes ou externes
• Aucun moyen d’évolution de sa plateforme pour répondre aux besoins des utilisateurs
• Une négligence de la maintenance et de l’infrastructure (voir idée 11) laissant la porte ouverte à la solution d’internalisation bâclée (voir idée 12)

Ne pas avoir les moyens de ses ambitions sur 24 à 36 mois constitue la pierre angulaire d’un échec inexorable sur ce délai.

5. Le business model

La notion de valeur peut varier d’un projet à un autre, que l’on soit sur un projet B2C, B2B, ou sur une solution digitale interne / métier. 

Néanmoins, la règle absolue de l’échec reste de pouvoir créer un projet dont le coût de build et de run est supérieur à la valeur générée, si tant est que cela soit possible de le mesurer, selon la formule :

 

((Coût de build) + (Coût de run mensuel)*12 ) - Valeur générée > 0

 

Voici quelques idées de financements, pouvant être combinés, pour réussir à coup sûr sa démarche d’échec financière :

 

• Une stratégie 100% basée sur le crowdfunding, démarré après la phase de build
• Une stratégie basée sur la vente de stickers en achats intégrés
• Une stratégie 100% basée sur des interstitiels de publicité
• Une stratégie basée sur des comptes payants obligatoires dès la version 1 de sa solution
• Une stratégie basée sur la vente de sa société dans 5 ans.

 

6. Les misfits  

 

Si avoir une équipe de « TopGun » de la tech ne vous garantira pas toujours le succès de votre projet, choisir une équipe de bras cassés sera pour le coup une garantie de son échec. 

 

Quelques règles sont à retenir pour bien choisir son équipe et son prestataire :

• N’avoir aucun individu dans votre équipe projet interne qui maîtrise la stack technique
• Déléguer l’ensemble de la mission de Product Owner à un(e) stagiaire en marketing
• Ne pas prendre un prestataire / agence mais composer soi-même son équipe de freelances, sans direction technique pour mentorer
• Choisir un prestataire non spécialiste de sa demande spécifique. Par exemple, demander une app mobile à un prestataire web, un site e-commerce à une agence de com’, ou un développement backend sur mesure à une entreprise d’objets connectés.
• Choisir un prestataire capable de s’engager au forfait sur la base d’un cahier des charges de 2 pages.
• Avoir une équipe de développement dont le « Lead Dev » est en alternance chez OpenClassRoom ou autre (mais attention, en formation intensive).
• Toujours privilégier les prestataires les moins chers

7. La méthodologie du tunnel

• 1 cahier des charges de 95 pages au moins + 
• 1 engagement forfaitaire strict +
• 1 première version à tester au bout de 6 mois, 1 semaine avant la mise en ligne théorique.

Voici le trio gagnant qui maximisera vos chances de tomber à côté des besoins de vos utilisateurs, et d’avoir entre 4 et 6 mois de retard sur votre roadmap.

Si le prestataire vous propose un format Agile / Scrum, avec des rituels hebdo, voire pire, daily, de suivi de votre projet, fuyez ! 

Vous risquez de garder le contrôle de la roadmap, et pis, d’avoir de bonnes idées en cours de route.

8. Le neveu designer

Votre neveu, ou l’amie de votre voisine est en école marketing / communication, et a récemment refait le logo du fleuriste en bas de chez vous pour 50€ ? Foncez ! Confiez-lui l’ensemble de votre identité graphique, mais surtout la conception UX/UI de votre plateforme.

Vous pouvez également vous lancer sur la création de logo, vous avez sans aucun doute de bonnes idées et du talent.

Une fois le travail terminé, veillez à mettre l’ensemble du travail réalisé sur un fichier Word, ou Powerpoint, afin de le transmettre aux développeurs, pour l’intégration. Mais ne dépensez surtout pas d’argent sur cette partie design : c’est à la portée de tout le monde !

9. La stack

Il existe une infinité ou presque de solutions techniques (langages / frameworks), avec cible privilégiée, avantages et inconvénients (même si sur certaines, avouons-le, nous cherchons encore les avantages).

L’enjeu ici sera de sélectionner LA stack hors sujet par rapport à votre besoin. Celle qui va permettre d’avoir un système instable, des performances plafonnées, des limitations techniques, un avenir limité, et une difficulté de réversibilité. 

Celle qui n’a pas été conçue pour faire ce que vous voulez, mais, comme cela arrange votre équipe de dev, et que vous ne comprenez rien, alors votre projet sera construit dessus.

Si en plus, vous avez la possibilité de choisir une solution non open-source, mais propriété de votre prestataire, vous avez gagné. Et plus généralement, si on vous parle de Cordova, Wix, Windev ou de « code maison » : foncez. 

10. Le lancement « all-in »

Votre projet est enfin prêt ! Vous l’avez reçu, testé, et grosse maille, tout semble fonctionner à peu près. En plus, vous avez quand même testé presque 1/2 journée sur 2 navigateurs, rien ne peut arriver. C’est donc le moment de lâcher les chevaux.

Important : ne lancez surtout pas votre produit petit à petit, sur un cercle initial restreint, puis un peu plus grand, puis enfin l’ensemble de vos cibles. Vous allez perdre du temps ! 

Lancez l’ensemble de la plateforme d’un coup, à tous vos utilisateurs. Faites de la publicité. Un max. Faites « all-in », tout va bien se passer ! Et votre prestataire est confiant. En plus, il a pris un serveur dédié sur OVH…

11. Le serveur

L’infrastructure : cette chose obscure qui arrive sur la table en fin de projet, et qui va vous coûter de l’argent que vous n’aviez pas prévu. Comment ? Un environnement cloud, sur mesure, et scalable à plusieurs centaines d’euros par mois ? Non mais ça va pas ?

Alors que vous venez de voir une superbe pub sur Gandi, avec un pack nom de domaine + serveur mutualisé pour 12€HT / mois. Si vous prenez la version à 25€HT / mois vous devez avoir une machine de guerre non ?

Ne perdez pas de temps sur l’infra. Comme pour le design, vous pouvez le gérer vous-même.

12. L’internalisation

Vous avez lancé votre projet, celui-ci commence à avoir une petite notoriété, et rencontre son public ? Ne désespérez pas, il est encore temps pour vous d’aller dans le mur. La meilleure solution est d’aller trop vite sur l’internalisation et de précipiter la réversibilité.

Idéalement, essayez vous-même de recruter un Dev dit « Fullstack », si possible en stage ou en alternance, ayant une belle maîtrise de Wix et des notions de PHP.

Demandez à votre prestataire un export « zip » des sources et un accès au « FTP » pour que votre stagiaire puisse reprendre le projet. 

Il y avait 5 experts côté prestataire sur la plateforme, avec un Dev back, un Dev front, un DevOps, un Archi web et un Scrum Master. Mais votre stagiaire est confiant, il a presque fini les tutoriels PHP sur Openclassroom. Foncez et faites lui confiance.

13. La confiance absolue

« Last but not least », un point crucial à l’échec de votre projet, et qui peut concerner toutes les autres catégories ci-dessus : la confiance absolue en vous-même. Vous avez raison, forcément. N’écoutez pas les soi-disant « sachants » ou spécialistes, qui iront peut-être challenger votre projet et vos idées. Votre idée ne peut que fonctionner.

En plus, vous avez vous même déjà installé un site sur Wix, fait quelques logos à l’époque de vos études avec votre version crackée de Photoshop, et vous avez connu moultes succès professionnels depuis. Alors certes, lancer une grosse plateforme digitale, vous n’avez jamais fait : mais vous pouvez y arriver sans l’aide d’autres personnes. Les personnes qui vont travailler avec vous vont le faire sous vos directives, et exécuter votre roadmap. Point. 

Après tout, « what could possibly go wrong » ?