Entre l'idée et la mise en production, il y a un moment où le budget s'engage sans qu'aucune hypothèse ait été confrontée à un utilisateur. Plus ce moment dure, plus l'erreur coûte cher à corriger. Quelques jours de test bien menés déplacent la décision d'investir sur du constaté plutôt que sur de la conviction.
Ils nous font confiance
Le projet est défendu par une conviction forte et aucune donnée.
Une conviction se teste en quelques jours, elle se corrige mal après six mois de développement.
Deux personnes du comité de direction ne décrivent pas le même produit.
Le désaccord se règlera en production, au prix fort, s'il ne se règle pas avant.
Vous avez un cahier des charges détaillé et aucun utilisateur interrogé.
La précision du document ne dit rien de la justesse de son hypothèse de départ.
Le budget engagé dépasse ce que vous pouvez vous permettre de perdre.
C'est le seuil exact à partir duquel un test préalable devient rentable.
Vous ne savez pas dire ce qui vous ferait renoncer au projet.
Sans critère d'abandon posé à l'avance, un projet ne s'arrête jamais, il s'épuise.
Le marché existe, mais vous ne savez pas si vos utilisateurs changeront d'habitude.
C'est la question qui fait échouer le plus de produits techniquement réussis.
Chaque étape se termine par un livrable utilisable et par une porte de sortie : vous pouvez vous arrêter là, ce qui a été produit continue de servir. Vous engagez donc une étape à la fois, et vous ajustez le périmètre à chaque jalon plutôt qu'au moment où il est trop tard pour le faire.
01 Cadrage
2 à 3 jours
Nous formulons ce que nous croyons vrai, sur qui, et ce qu'il faudrait observer pour s'en convaincre. Nous écrivons aussi, dès ce moment, le résultat qui ferait renoncer au projet : c'est ce qui distingue un test d'une démonstration destinée à rassurer.
Livrable l'hypothèse formulée, les critères de réussite et le critère d'abandon.
02 Exploration
3 à 5 jours
Quelques entretiens ciblés suffisent à faire tomber une hypothèse fausse. Nous parlons à des personnes qui ont le problème, pas à celles qui trouvent l'idée sympathique, et nous écoutons ce qu'elles font aujourd'hui plutôt que ce qu'elles disent qu'elles feraient.
Livrable la synthèse des entretiens et les hypothèses qui ne tiennent plus.
03 Conception
3 à 5 jours
Nous maquettons le chemin principal, cliquable, sans aucun développement. L'objectif n'est pas de montrer le produit fini mais de provoquer un comportement observable : est-ce que la personne comprend, avance, et va jusqu'au bout.
Livrable un prototype cliquable et le protocole de test.
04 Test
2 à 3 jours
Cinq utilisateurs représentatifs révèlent l'essentiel des blocages. Nous observons ce qu'ils font, pas ce qu'ils pensent de l'idée, et nous acceptons le résultat, y compris quand il invalide le projet. Un test qui ne pouvait qu'être positif n'était pas un test.
Livrable les observations de test et la décision : construire, ajuster ou renoncer.
05 Décision
2 jours
Si l'hypothèse tient, on pose le périmètre de la première version réellement utile et son ordre de grandeur. Si elle ne tient pas, la mission s'arrête ici : c'est le scénario le moins cher du projet, et il arrive régulièrement.
Livrable le périmètre de la première version, son estimation et les risques restants.
06 Construction
4 à 8 semaines
La première version ne reprend que ce que le test a confirmé, mis en service devant de vrais utilisateurs. Le reste attend d'être demandé par l'usage plutôt que par la réunion de lancement.
Livrable la première version en service et son plan de mesure.
Décrivez votre contexte, vos outils et votre échéance : vous repartez avec un périmètre de départ et un ordre de grandeur budgétaire. Ce que vous saisissez nous sert de base au premier échange, vous n'aurez pas à le redire.
Un test ne sert à rien quand la décision est déjà prise. Si le projet est engagé auprès d'un client, annoncé publiquement ou porté par quelqu'un qui ne peut plus reculer, le test ne fera que produire une justification coûteuse. Il échoue aussi quand on teste sur des personnes complaisantes, ou quand aucun critère d'abandon n'a été écrit avant de commencer. Nous posons donc ce critère dès le premier jour, nous recrutons des utilisateurs qui ont réellement le problème, et quand la vraie question est un arbitrage politique interne, nous vous le disons plutôt que de vendre un sprint.
McKinsey et université d’Oxford, 5 400 projets informatiques
Un prototype se construit avec le minimum de technique nécessaire pour provoquer un comportement réel. Selon ce que nous cherchons à observer, ce sera une maquette cliquable, un enchaînement d'automatisations, ou une brique d'IA branchée sur quelques documents. Ce qui compte est la fidélité de l'expérience testée, pas la solidité du code jetable.
Votre projet ne mobilise pas les mêmes compétences selon l'endroit où il bloque : de la recherche utilisateur quand le besoin est encore flou, un design system quand l'outil devra grandir, un renfort produit quand ce qui manque est la décision plus que les mains. Le pilotage reste le même d'un bout à l'autre de la mission, l'équipe autour se compose sur votre sujet.
Depuis 15 ans
Quinze ans à concevoir, développer et mettre en service des produits numériques : product managers, designers et développeurs qui ont vu passer les cycles et savent ce qui tient en production. Nous partons du problème métier plutôt que de la technologie, et nous allons jusqu'à la mise en service au lieu de nous arrêter à la recommandation.
70+ projets livrés
Le pilotage du projet reste chez nous, du premier atelier à la mise en service : c'est ce qui permet de décider vite quand une hypothèse tombe en cours de route. Autour de ce noyau, nous mobilisons les expertises que votre sujet demande vraiment, et non l'inverse, où le profil disponible finit par dicter la solution.
Sans licence ni redevance
Dès le paiement, sans licence ni redevance : le code, les maquettes et la documentation vous sont livrés, et une autre équipe peut les reprendre. Nous ne vendons pas d'accès à une plateforme qui resterait la nôtre.
Savoir dire non
Quand un logiciel du marché couvre l'essentiel du besoin, quand un process change encore tous les mois, quand la donnée n'est pas prête : nous le disons au cadrage, avant le devis. Un projet mal parti coûte plus cher à tout le monde qu'un projet refusé.
Financement public
Pégase Digital est affilié au Crédit d'Impôt Innovation. Une entreprise soumise à l'impôt en France peut, sous conditions, prétendre à un crédit d'impôt équivalant à 20 % des dépenses externalisées de conception et de développement, quand la solution est nouvelle et innovante sur son marché de référence. L'éligibilité s'apprécie projet par projet, avec votre conseil fiscal.
Votre entreprise a moins de deux ans ? Le remboursement immédiat peut être demandé plutôt qu'imputé sur l'impôt des exercices suivants.
Un enjeu en amène souvent un autre.
Saisies manuelles, exports récurrents, relances à heure fixe : chaque tâche répétée est du temps que vos équipes ne passent pas ailleurs.
Vous savez que l'intelligence artificielle peut servir, sans savoir où la brancher ni comment la cadrer pour qu'elle tienne en conditions réelles.
Vos process tiennent sur des fichiers partagés, des mails et des habitudes que personne n'a jamais écrites.
Vous collectez des données depuis des années sans qu'aucune décision ne s'appuie vraiment dessus.
Une idée qui en accumule d'autres sans cadrage, ou un produit qui fonctionne mais que vos utilisateurs n'utilisent pas.
Votre trafic monte, vos demandes entrantes non, et personne ne sait dire quel canal a amené le dernier client signé.
Vos clients passent du site à l'application puis en boutique, et doivent tout réexpliquer à chaque fois.
De quelques jours à deux semaines selon la question posée. Valider qu'un problème existe demande des entretiens et se fait en une semaine. Valider qu'une solution est comprise et utilisable demande un prototype testé, soit une à deux semaines de plus. Au-delà de deux semaines sans décision, ce n'est plus un test, c'est un projet.
Cinq utilisateurs représentatifs révèlent l'essentiel des blocages d'un parcours, c'est un résultat établi de longue date en recherche utilisateur. Ce qui compte davantage, c'est leur profil : cinq personnes qui ont réellement le problème valent mieux que vingt personnes bienveillantes de votre entourage professionnel.
La mission s'arrête, et c'est le meilleur retour sur investissement du projet. Vous avez dépensé quelques jours au lieu de plusieurs mois, et vous savez pourquoi. Dans la plupart des cas, le test ne tue pas l'idée mais déplace le problème : le besoin existe, il n'est simplement pas là où vous le pensiez.
Non, c'est un objet jetable qui sert à provoquer une réaction. Il n'a ni base de données, ni comptes, ni cas particuliers, et son code n'a pas vocation à être repris. Confondre les deux est une erreur coûteuse : un prototype poussé en production devient un produit impossible à maintenir.
Un prototype teste une hypothèse sans être mis en service. Un produit minimum viable (MVP) est une vraie première version, en production, avec de vrais utilisateurs et de vraies données. Le prototype vient avant et coûte dix fois moins cher : il sert justement à décider quel MVP mérite d'être construit.
Souvent oui, et c'est même là que le test rapporte le plus. Un cahier des charges décrit une solution en détail, sans jamais vérifier l'hypothèse qui la fonde. Deux semaines de test avant le lancement du développement coûtent une fraction du budget et évitent la correction la plus chère : celle qu'on découvre après la mise en production.
