Démo interactive · Semaine 1 de chaque prototype
Un aperçu du prototype avant de vraiment le construire.
Voici Munch, une mangeoire connectée pour animaux et son application mobile. Ni l'une ni l'autre n'existent, mais la logique du firmware et de l'application, elle, tourne ici même. Sur de vrais projets, Atallis construit un aperçu comme celui-ci à partir de votre idée dès la première semaine, pour débattre du comportement avant de débattre des composants.
L'histoire de Munch
- L'idée
Une mangeoire fiable, même depuis une chambre d'hôtel
Maya voyage pour le travail deux nuits par semaine. Son chat Biscuit, lui, reste à la maison. Elle veut des repas à l'heure, une gâterie quand il lui manque, et une alerte sur son téléphone si quelque chose tourne mal.
- Semaine 1 · Premier aperçu
« Il appuierait sur ce bouton toute la journée »
Avant qu'une seule pièce soit commandée, Maya reçoit un lien. En quelques minutes, elle le voit : Biscuit va apprendre à se servir du bouton. On ajoute une limite quotidienne de gâteries. Ici, c'est un menu déroulant ; après l'outillage, c'est une mise à jour du firmware.
- Semaine 1 · La vraie question
Et si Internet coupe pendant son absence ?
Continuer à nourrir, ou attendre ? On décide ensemble : la mangeoire suit sa propre horloge, garde la trace de ce qui s'est passé et synchronise au retour de la connexion. L'application affiche « hors ligne » honnêtement, au lieu de faire semblant.
- Semaine 2 · Le cas que personne n'avait prévu
Un moteur bloqué, c'est un chat affamé
L'aperçu nous force à écrire le comportement exact : arrêter le moteur, clignoter en rouge et dire à Maya combien de portions sont réellement sorties. Cette phrase devient une exigence pour le matériel.
- Bleu qui respire : en ligne
- Une DEL qui clignote : pas de Wi-Fi
- Ambre : nourriture basse
- Rouge : blocage ou réservoir vide
Appuyez sur le bouton du couvercle pour une gâterie · Glissez pour faire pivoter
Conditions de test
Modifier le cahier des charges
Chacun de ces choix est une décision produit. Ici, il coûte un clic ; après l'outillage, il coûte une révision de carte.
Journal d'événements
Fondatrice fictive, processus réel.
À la fin de la deuxième semaine, Maya a approuvé le comportement de Munch en cliquant dessus, pas en lisant un document, et le schéma électronique part de là. Maya et Munch sont fictifs, mais le processus est très représentatif du début d'une collaboration avec Atallis : nous limitons la documentation à ce qui est utile et faisons des démos autant que possible. Un long cahier des charges se survole. Un aperçu se clique, et chaque clic règle une question pendant qu'il est encore peu coûteux de changer la réponse.
J'aime les surprises. Mais pas sur votre projet ;-) Mieux vaut les trouver ici, en semaine 1, que sur l'établi en semaine 8.
Qu'est-ce qu'un aperçu du prototype ?
Un aperçu du prototype est une simulation cliquable du comportement de votre produit, construite avant que le matériel existe. Il exécute la même logique que le firmware et l'application : états, boutons, voyants, alertes, horaires et connectivité. Vous, votre équipe et vos futurs utilisateurs l'essayez dans un navigateur, sur n'importe quel appareil.
Chez Atallis, l'aperçu est construit dès la première semaine d'un mandat de prototypage, à partir de l'appel de découverte et de vos notes. Ce n'est pas un produit à acheter séparément. C'est la façon dont le mandat commence.
Ce qu'il permet de repérer tôt
- Les comportements que personne n'a écrits. Ce qui se passe quand Internet coupe, quand la pile faiblit, quand deux commandes arrivent en même temps ou quand quelqu'un appuie dix fois sur le bouton.
- Les désaccords entre l'appareil et l'application. Lequel fait foi, ce que l'application affiche quand l'appareil est hors ligne, et comment les événements se resynchronisent.
- Les modes de défaillance. Blocages, réservoir vide, capteur en défaut : ce que fait l'appareil, ce que voit l'utilisateur, ce qui est journalisé.
- Les limites du produit. Plafonds quotidiens, délais, seuils d'alerte. Chacun devient une ligne du cahier des charges plutôt qu'une surprise sur l'établi.
Sa place dans le processus
Semaine 1 : nous planifions ensemble, puis vous recevez un premier aperçu du comportement. Semaines 2 à 3 : l'aperçu évolue au fil des décisions, et l'architecture matérielle part du comportement que vous avez approuvé. Semaines 4 à 7 : le prototype physique est construit et testé selon les mêmes scénarios que l'aperçu a rendus explicites.
Nous limitons la documentation à ce qui est utile. Un long cahier des charges se survole ; un aperçu se clique, et chaque clic règle une question pendant qu'il est encore peu coûteux de changer la réponse.
Ce que vous recevez
- Un lien à partager avec votre équipe, vos investisseurs ou vos utilisateurs test.
- Un cahier des charges du comportement, rédigé à partir des scénarios que vous avez approuvés, et non d'hypothèses.
- Des scénarios de test réutilisés ensuite pour vérifier le prototype physique.
Ce qu'il ne remplace pas
Un aperçu modélise le comportement, pas la physique. L'autonomie de la pile, la portée radio, le couple d'un moteur, les limites thermiques et la CEM doivent toujours être mesurés sur du vrai matériel. L'aperçu garantit qu'au moment de mesurer, nous sommes déjà d'accord sur ce que le produit doit faire.
Questions sur les aperçus de prototype
- L'aperçu, est-ce le vrai firmware ?
- Non. Il reproduit la logique du firmware (états, délais, règles) dans le navigateur pour pouvoir la tester avant que le matériel existe. Le firmware de production est écrit pour le microcontrôleur réel, en utilisant le comportement de l'aperçu comme cahier des charges.
- Un aperçu coûte-t-il plus cher ?
- Non. Dans les mandats de prototypage Atallis, l'aperçu fait partie de la première phase. Ce n'est pas une option.
- Mes utilisateurs ou mes investisseurs peuvent-ils l'essayer ?
- Oui. Il fonctionne dans tout navigateur récent, sur ordinateur ou sur téléphone. Partager un lien est souvent le moyen le plus rapide de recueillir des commentaires avant de s'engager sur une conception.
- Pour quels produits est-ce utile ?
- Pour tout produit dont le comportement compte autant que l'électronique : appareils connectés avec une application, produits avec boutons, voyants ou écran, instruments avec des modes et des alarmes. C'est moins utile quand le risque principal est purement physique, comme la précision d'un capteur ou la portée radio.
- Munch est-il un vrai produit ?
- Non. Munch et Maya sont fictifs, créés pour montrer le processus. Les aperçus de nos clients restent confidentiels, sous entente de non-divulgation.
Vous avez l’idée.
Rendons-la réelle.
Une conversation suffit pour savoir si on est un bon match. Pas de jargon, pas d’engagement, juste un regard honnête sur ce qu’il faut pour bâtir votre prototype.