Intrapreneuriat augmenté : la méthode POC en 5 jours

Avant 2024, livrer un POC crédible en entreprise prenait entre 3 et 9 mois. Aujourd'hui, la bonne nouvelle : 5 jours suffisent. La mauvaise nouvelle : la majorité des entreprises n'ont pas encore ajusté leurs process internes pour en profiter.

Voici la méthode que nous appliquons dans nos sprints POC 5 jours, testée sur une quarantaine de cas depuis 2024. Ce n'est pas une théorie — c'est un script exécutable.

Jour 0 — Le cadrage (avant le sprint)

Avant le lundi matin, vous devez avoir répondu à trois questions :

Quelle est l'hypothèse à tester ? Pas "est-ce que ce marché est intéressant ?" — trop vague, invalidable. Mais "est-ce que 3 commerciaux sur 10 préfèrent notre nouvel outil à leur Excel actuel ?" — précis, mesurable.

Qui va vraiment l'utiliser ? Nommez 3 à 5 personnes en interne qui testeront le POC le vendredi. Sans ces noms validés, pas de sprint. C'est le garde-fou le plus sous-estimé : il évite les POCs qui "seraient peut-être utiles à quelqu'un un jour".

Quel budget de temps ? Cinq jours d'une équipe de 3 à 5 personnes. Pas plus. Pas moins. Si vous ne pouvez pas bloquer 5 jours pleins pour votre équipe, attendez un mois et re-cadrez. Un sprint à temps partiel ne marche jamais.

Jour 1 — Designer, pas construire

La tentation est de démarrer bolt.new lundi matin. Erreur.

Jour 1 est un atelier de design. Quatre exercices :

Matin : cartographie du workflow existant. Comment la personne fait-elle aujourd'hui ? Tableau blanc, post-its, pas de laptop. 2 heures.

Déjeuner : interview utilisateur filmée. Une des 3 personnes cibles vient expliquer son quotidien. 30 minutes. Préserver la vidéo.

Après-midi : paper prototype. Trois écrans dessinés à la main. Test avec une autre personne cible. Ajustements.

Fin de journée : brief écrit, 1 page, sur Notion. Il contient l'hypothèse, les 5 testeurs, les 3 écrans, le critère de succès du vendredi.

À la fin du jour 1, personne n'a ouvert un outil de dev. Personne n'a écrit une ligne de code. Vous savez exactement ce que vous allez construire. 80% des POCs qui échouent ratent ce jour 1.

Jour 2 — Le squelette IA-first

Mardi matin, bolt.new ou Lovable. Le prompt de départ ressemble à ceci :

Je veux construire un prototype web Next.js + Tailwind + Supabase. [Brief page 1 du doc Notion]. Étape 1 : construis uniquement l'écran 1 (le plus complexe). Aucune logique métier pour l'instant, juste l'UI avec des données en dur.

En une matinée, vous avez un prototype cliquable sur trois écrans. Pas de base de données, pas d'auth — juste des écrans.

L'après-midi, deuxième itération : vous branchez Claude Code ou Cursor en complément, et vous commencez à ajouter la logique métier. Un formulaire qui poste des données, une liste qui s'affiche, un filtre qui marche.

À la fin de la journée, le prototype répond aux inputs. Il simule le flux. Il n'est pas encore connecté à vos vraies données.

Jour 3 — L'intégration réaliste

Mercredi, le cœur technique : connecter le prototype à au moins une source de données réelle. Pas vos données prod (trop risqué) — un jeu de données exporté, anonymisé si nécessaire, mais réaliste.

Trois options, par ordre de vitesse :

1. CSV ou Excel importé dans Supabase. 2 heures. Parfait pour 80% des cas.
2. API interne sandboxée. Une demi-journée. Requiert un contact DSI. Si vous n'avez pas de contact, voyez option 1.
3. Base prod read-only via tunnel. À éviter le jour 3 — trop d'angles morts.

À la fin de mercredi, le prototype affiche vos vraies données et réagit à elles. Pas de beauté à ce stade, juste la mécanique.

Jour 4 — Polish + tests internes

Jeudi est le jour du polish. Responsive mobile si pertinent, dark mode si votre culture interne le demande, gestion des erreurs minimale, loading states, quelques animations.

L'après-midi, trois tests utilisateurs de 30 minutes chacun. Pas avec vos 5 cibles finales — avec 3 profils similaires non-sponsor du projet. Vous notez les points de friction. Vous corrigez les 2 plus critiques.

À 18h, le prototype est testable par un utilisateur qui n'a jamais vu l'interface.

Jour 5 — Test + décision

Vendredi matin, tests avec les 5 utilisateurs cibles. 45 minutes par personne. Une grille d'observation (pas un questionnaire) avec 5 critères : complétion de la tâche, temps, frustration, enthousiasme spontané, intention de ré-utiliser.

Vendredi après-midi, restitution à votre sponsor. Un seul slide : la décision.

Trois décisions possibles :

GO : 4 utilisateurs sur 5 sont enthousiastes, le POC valide l'hypothèse. On chiffre la version industrielle, on réserve un slot DSI, on embarque le legal.

PIVOT : 3 utilisateurs sur 5 voient l'intérêt mais pas avec cette forme. On re-cadre. Nouveau sprint dans 4 semaines avec un autre angle.

KILL : les utilisateurs n'accrochent pas, l'hypothèse est invalidée. On documente le post-mortem — c'est la partie précieuse — et on passe à autre chose. Pas de honte : un POC qui prouve qu'une idée ne marche pas a fait économiser 6 mois à l'entreprise.

Les erreurs classiques

Après 40+ sprints, on connaît les 3 causes d'échec :

1. Sponsor absent. Si votre sponsor n'est pas physiquement ou virtuellement présent aux moments clés (jour 1 cadrage, jour 5 restitution), le POC aboutit rarement. Un sponsor qui délègue à un chef de projet ne compte pas.

2. Pas de vrais utilisateurs testeurs. Tester avec des collègues du même département biaise tout. Les vrais utilisateurs sont parfois inaccessibles sur 5 jours — c'est un vrai problème, pas un détail à contourner.

3. Vouloir construire trop. Quatre écrans au lieu de trois. Une intégration complexe en plus. Le sprint dérape vendredi, le vendredi devient samedi, le samedi devient "on finira la semaine prochaine". Morts de ces POCs.

Ce que ça donne concrètement

Depuis 2024, nos sprints ont livré :

• Un copilote interne SAV pour 2 300 salariés (Nordkraft), industrialisé en Q2 2026.
• Un outil de génération de rapports mensuels pour 12 chefs de projet retail (Maison Briq), 800h/an économisées.
• Un triage automatique de tickets support pour une fintech (Velora), déployé après 3 POCs successifs.
• 8 POCs "KILL" qui ont fait économiser 2 M€ cumulés en projets abandonnés avant qu'ils ne démarrent.

La méthode n'est pas magique. Elle est reproductible. C'est la raison pour laquelle on la partage, et qu'on peut la livrer clé en main en cinq jours chez vous.