Playbook de développement de produit IoT de bout en bout – Étape 0 : Concept & faisabilité

Cliquez pour le chapitre précédent : Introduction

« Attendez — devrions-nous vraiment construire cette chose ? »

La plupart des produits IoT ratés ont été perdus avant même le premier schéma : personne n’a vérifié si l’idée valait la peine d’être construite. L’Étape 0 existe pour répondre à cette question avec des preuves plutôt qu’avec de l’enthousiasme. Imaginez-vous à l’orée d’une jungle dense, machette à la main. Vous entendez qu’il pourrait y avoir un trésor au-delà des vignes — des rumeurs de clients reconnaissants, de decks d’investisseurs élogieux, peut-être même le mythique Series B. Mais vous sentez aussi les trous de boue et les insectes affamés prêts à ronger votre runway. Un sprint Concept & faisabilité discipliné vous dit si la chasse au trésor justifie d’ouvrir un passage. Les équipes pressées sautent souvent cette étape (« Commençons les sprints tout de suite ! »). Ne le faites pas. Quelques jours concentrés ici économisent des mois de retravail, dissipent le brouillard du vœu pieux et donnent à l’équipe un cri de ralliement qui survit aux longues nuits de débogage de firmware à 2 h du matin.

0.1 Pourquoi ce chapitre est-il si important ?

Parce que chaque barre de Gantt, chaque ticket Jira et chaque bon de commande en aval hérite de sa raison d’être de la décision que vous prendrez ici. Si vous vous lancez dans la capture de schémas ou le wireframing d’application mobile sans un « Pourquoi » clair et fondé sur des preuves, vous louez un bulldozer avant de savoir si vous avez besoin d’un parterre de fleurs ou d’un gratte-ciel. Les équipes qui sautent la faisabilité finissent aussi par vendre des rêves flous aux parties prenantes : « C’est comme un Fitbit, mais pour les chats, et en plus ça mine de la cryptomonnaie ! » Divertissant — jusqu’à ce que la Finance demande le coût du Bluetooth mesh sur un collier que Fluffy adore mâchouiller.

0.2 Les quatre conversations que vous devez avoir

1. Entretien sur les points de douleur

Trouvez un véritable humain (ou plusieurs) qui vit le problème au quotidien. Écoutez plus que vous ne parlez. S’ils n’utilisent pas de langage salé ou ne soupirent pas lourdement en décrivant la douleur, le problème n’est probablement pas assez aigu pour justifier le burn rate d’une start-up matérielle.

Exemple : Un responsable d’installations avoue qu’il perd des milliers d’euros par mois parce que personne ne remarque quand le congélateur industriel dépasse −15 °C à 3 h du matin.

2. Énoncé de vision

Distillez ce que vous avez entendu en une phrase qui tient sur une tasse à café. « Nous donnons aux responsables d’installations une alerte précoce des pannes d’équipement — avant que la glace ne fonde. » Si la phrase semble molle ou essaie de plaire à tout le monde, continuez à tailler.

3. Parcours utilisateur de haut niveau

Tracez une simple storyboard : le responsable reçoit une notification push, appuie pour ouvrir un graphique de tendance, envoie la maintenance, et savoure tranquillement un bun à la cannelle parce que la catastrophe a été évitée. Pas de pixel-pushing d’UI pour l’instant — pensez bande dessinée, pas maquettes haute fidélité.

4. Vérification de santé du marché

Ouvrez un tableur (oui, cette redoutable grille vide) et répondez : À quelle fréquence cette douleur se produit-elle ? Combien de personnes l’ont ? Que paierait chacune pour en être soulagé ? Les rapports sectoriels, les prix des SKU concurrents sur Digi-Key et un rapide comptage LinkedIn des titres « Facilities Manager » dans votre région cible vous donneront une précision respectable. Les PM débutants s’inquiètent des décimales ; les vétérans s’inquiètent des ordres de grandeur.

0.3 Expériences de faisabilité rapides

Le développement matériel peut sembler glaciaire, mais vous pouvez générer des preuves convaincantes en quelques jours :

• Test de fumée de portée – Prenez un kit de développement BLE tout fait, mettez-le dans un congélateur en inox, faites-lui un ping depuis le couloir, mesurez le RSSI. Si le signal meurt à deux mètres, vous venez d’éviter une erreur de connectivité avant de commander des PCBs personnalisés.
• Vérification de véracité du capteur – Empruntez une sonde de température étalonnée, collez-la à côté de votre capteur numérique candidat, et enregistrez 12 h de données. Le capteur bon marché dérive-t-il de 3 °C à chaque démarrage du compresseur ? Écartez-le tôt.
• Démo pour les parties prenantes – Canalisez les données du kit de développement vers un tableau de bord cloud gratuit (ThingSpeak, Adafruit IO) et montrez-le à votre responsable d’installations. S’il demande : « Est-ce que je peux acheter ça demain ? », vous tenez quelque chose. S’il hausse les épaules, affinez ou pivotez.

0.4 Artefacts à emporter (rien de fancy)

1. One-pager de vision – Elevator pitch, utilisateur cible, douleur viscérale, résultat proposé.
2. Storyboard de trois cases – Identifiez le déclencheur, l’action et le résultat. Un croquis approximatif suffit ; des photos de téléphone de post-it comptent.
3. Tableau TAM/SAM/SOM – Estimations de marché Total, Adressable et Réalisable. Dix lignes suffisent. Incluez votre score de confiance et les liens de citation.
4. Mémo du sprint de faisabilité – Une page : Hypothèse → Expérience → Données → Verdict → Prochaine étape. Lisible en trois minutes par votre VP.

Ces artefacts ne sont pas de la cérémonie pour la cérémonie. Ils agissent comme des balises d’alignement : quand le marketing veut chasser une autre persona ou que l’ingénierie propose une radio mmWave exotique, vous pouvez brandir le one-pager et demander : « Est-ce que cela sert notre histoire de responsable d’installations qui sauve des congélateurs ? »

0.5 Coût de l’omission

Encore tenté de déclarer « construisez-le et ils viendront » ? Un conte de garde au dos de l’enveloppe : une équipe que j’ai mentorée a dépensé 60 000 € en spins de PCB avant de réaliser que les hôpitaux — leur marché cible — n’autorisent pas les radios 2,4 GHz dans les salles d’IRM. Un test de fumée de faisabilité de deux heures avec un analyseur de spectre emprunté aurait fait gagner huit mois et la démission d’un ingénieur.

0.6 Construire le rituel Go/No-Go

Les humains — surtout les ingénieurs nourris au plaisir des LEDs qui clignotent — détestent dire « Non ». Institutionnalisez-le. Mettez une invitation calendrier pour une Feasibility Review exactement deux semaines après le kickoff du projet. Invitez une personne chacune du business, de l’ingénierie, de la qualité et du customer success. Présentez vos quatre artefacts, démontrez les prototypes rapides éventuels, et terminez la réunion par un vote forcé : Go ou No-Go (un pivot compte comme No-Go). La majorité l’emporte. Consignez la décision dans votre wiki avec un timestamp et la liste des participants. Le vous-du-futur remerciera le vous-du-passé quand les auditeurs ou les investisseurs demanderont : « Pourquoi avez-vous parié la ferme sur LoRa plutôt que NB-IoT ? »

0.7 Pièges courants de débutant et comment les éviter

0.8 Mini étude de cas : le sprint Smart-Freezer d’une semaine

Lundi : Deux PM interrogent trois responsables d’installations, confirment que la détérioration des congélateurs coûte 10 k€ par incident.
Mardi : Le lead hardware monte un capteur de température I²C à 12 $ sur une carte de développement Wio-Link, stream du JSON vers Adafruit IO.
Mercredi : Le stagiaire cloud construit un panneau Grafana et une alerte SMS via Twilio.
Jeudi : Les PM poussent une vidéo de démo aux parties prenantes ; le CFO lâche : « Si ça marche, on économise 1 M€ par an sur tous les sites. »
Vendredi : La Feasibility Review vote Go, mais impose de vérifier le backhaul cellulaire là où le Wi-Fi est capricieux.

Dépense totale : 300 € en pièces et pizza. Clarté gagnée : inestimable.

0.9 La checklist du chapitre 0 (imprimez, annotez, collez au-dessus de votre écran)

1. Énoncé du problème capturé en une phrase brutalement courte.
2. Au moins un entretien avec une personne souffrant du problème, citations consignées verbatim.
3. Énoncé de vision partagé sur Slack, réactions collectées (si personne ne réagit, réécrivez).
4. Deux à trois croquis de parcours utilisateur photographiés et téléversés.
5. Premiers chiffres de santé du marché dans un tableur, étiquetés avec les liens des sources.
6. Une expérience de faisabilité menée, données graphées.
7. Blocage calendrier pour la revue Go/No-Go fait ; arbitre neutre invité.
8. Décision consignée, lien collé à la racine du dépôt du projet.
9. Si Go → risques de haut niveau & responsable du chapitre suivant assignés.
10. Si No-Go → un mot de remerciement envoyé à l’équipe ; leçons apprises documentées.

Collez cette checklist sur le capot de votre laptop. La prochaine fois que vous serez tenté de sprinter parce que « le fabricant de PCB a une promo qui se termine ce soir », jetez un œil à la case n° 1. Si vous ne pouvez pas réciter l’énoncé du problème en cinq secondes, vous n’êtes pas prêt à commander du cuivre.

0.10 Pour conclure

Concept & faisabilité est le plus petit chapitre en temps calendaire — mais le plus grand en impact. Traitez-le comme le prologue d’un bon roman : sautez-le et le reste de l’intrigue semble confus et creux. Investissez une bouffée d’énergie concentrée ici, et chaque chapitre suivant s’enclenche. Vos ingénieurs vous remercieront, vos investisseurs hocheront la tête devant une articulation nette de la valeur, et vos utilisateurs recevront finalement un produit qui sauve vraiment leurs miches (ou leur glace).

Puis passez au chapitre 1, où nous transformons les aspirations floues en System Requirements bien définies — si claires que même votre futur auditeur de conformité esquissera un sourire.