BlogMéthode · 19 octobre 2026
Du prototype IA au produit fiable : ce qu'on garde
Maquette, prototype, MVP : trois objets différents. Ce qu'un prototype créé avec un agent IA apporte, et ce qu'il faut reprendre avant la production.
Vous avez construit un prototype avec un agent IA. Il tourne, il montre l'idée, il a peut-être déjà convaincu un associé ou un premier client. La question suivante est presque toujours la même : peut-on partir de là, ou faut-il tout recommencer ? La réponse honnête est rarement l'un ou l'autre. Un prototype contient des choses précieuses et des choses qui ne tiendront pas la charge. Le travail consiste à les distinguer, puis à reprendre ce qui doit l'être sans perdre ce qui a été appris.
Maquette, prototype, MVP : trois objets différents
Avant de parler de reprise, il faut nommer ce que l'on a entre les mains. Les trois mots sont souvent confondus, et la confusion coûte cher.
La maquette montre des parcours
Une maquette illustre des écrans et l'enchaînement entre eux. Elle sert à se mettre d'accord sur ce que l'utilisateur voit et fait. Elle ne stocke rien de durable, ne gère pas de vrais comptes et ne protège aucune donnée. Une maquette ciblée peut se produire très vite, une fois le besoin cadré : c'est un outil de décision, pas un produit.
Le prototype prouve qu'une idée fonctionne
Le prototype va plus loin : il exécute une partie de la logique. C'est souvent là que les agents IA brillent. En quelques échanges, ils produisent un écran qui interroge une base, un formulaire qui enregistre, un tableau qui calcule. Le prototype répond à la question « est-ce que ça peut marcher ? ». Il ne répond pas à « est-ce que ça peut tourner tous les jours, pour de vrais utilisateurs, avec de vraies données ? ».
Le MVP est une première version utilisable
Eric Ries, qui a popularisé le terme dans The Lean Startup, décrit le produit minimum viable comme la version qui permet d'apprendre le plus avec le moins d'effort. Dans la pratique d'un projet logiciel, un MVP est une première version réellement utilisable, limitée en fonctions, mais fiable sur ce qu'elle fait. C'est cette fiabilité qui le sépare du prototype.
Ce qu'un prototype apporte, et qu'il faut garder
Il serait faux de traiter un prototype comme un brouillon jetable. Il contient souvent ce qu'un cahier des charges peine à exprimer.
Les parcours validés. Si des utilisateurs ont essayé le prototype, leurs réactions valent de l'or. L'ordre des écrans, les intitulés qui ont été compris, les étapes qu'ils ont sautées : tout cela se conserve.
Le vocabulaire métier. Les noms donnés aux objets (dossier, intervention, commande, lot) reflètent la façon dont l'activité pense. On les garde dans le modèle de données final.
Les règles découvertes en route. En construisant vite, on tombe sur des cas que personne n'avait prévus : un devis qui change de statut deux fois, un client rattaché à deux sites. Ces règles doivent être notées avant toute reprise.
Parfois, une bonne partie de l'interface. Des composants d'écran bien découpés peuvent survivre, surtout s'ils reposent sur des bibliothèques standards.
Ce qu'il faut presque toujours reprendre
Un prototype généré rapidement fait des choix par défaut. Ce sont ces choix qu'il faut examiner un par un.
L'architecture et les données
Le prototype a souvent un modèle de données construit au fil de l'eau : des champs dupliqués, des relations implicites, aucune contrainte en base. Tant qu'il n'y a qu'un utilisateur de test, cela passe. Avec des données réelles, les incohérences s'accumulent. La reprise commence en général par un modèle de données propre, avec des relations explicites et des règles de validation côté serveur.
Les autorisations
C'est le point le plus sensible. Beaucoup de prototypes vérifient les droits dans l'interface seulement : le bouton est masqué, mais l'action reste possible si on appelle directement le serveur. Le classement OWASP Top 10, référence publique des risques des applications web, place le contrôle d'accès défaillant en tête de sa liste. Chaque action doit être vérifiée côté serveur, pour chaque utilisateur et chaque donnée.
Les tests, la performance et l'exploitation
Un produit fiable se teste de façon automatique, se surveille en production et se déploie sans manipulation risquée. Il faut des journaux d'erreurs lisibles, des sauvegardes, un environnement de préproduction. Rien de cela n'existe en général dans un prototype, et c'est normal : ce n'était pas son rôle.
Comment se déroule l'évaluation
Chez Hultra Studio, la reprise d'un prototype commence par une lecture, pas par une réécriture. Nous regardons le code, le modèle de données, les dépendances, les accès, puis nous rendons un avis clair : ce qui peut être conservé, ce qui doit être repris, et dans quel ordre. Ce tri est guidé par le risque. On sécurise d'abord ce qui touche aux données et aux droits, ensuite ce qui touche à la stabilité, enfin ce qui touche au confort.
Cette approche est décrite plus en détail sur la page la méthode Hultra. Elle repose sur une idée simple : l'IA accélère la production, des experts humains donnent la direction et répondent de la qualité.
Les signaux qu'il est temps de passer au produit
Certains signes indiquent que le prototype a fait son travail et qu'il faut changer de régime :
de vraies personnes commencent à y saisir de vraies données ;
plusieurs rôles doivent coexister (administrateur, collaborateur, client) ;
une panne aurait un coût pour l'activité ;
chaque nouvelle fonction en casse une autre ;
personne ne sait vraiment comment le déployer à nouveau.
Si deux ou trois de ces signaux sont présents, la reprise n'est plus une option de confort. C'est une condition pour continuer à avancer.
Questions fréquentes
Faut-il jeter mon prototype généré par IA ?
Rarement en totalité. Les parcours, le vocabulaire métier et les règles découvertes se conservent presque toujours. Le code lui-même se trie : certaines parties sont reprises, d'autres réécrites selon le risque qu'elles portent.
Combien de temps prend la reprise d'un prototype ?
Cela dépend de son périmètre et de son état. Une évaluation permet de répondre avec précision ; toute estimation donnée avant de lire le code serait une supposition.
Une maquette peut-elle être mise en production ?
Non. Une maquette illustre des parcours. Elle ne gère ni vrais comptes, ni données durables, ni autorisations. Elle sert à décider avant de construire.
Sources
Eric Ries, The Lean Startup, Crown Business, 2011.
Blog
À lire aussi
Les derniers articles publiés.
Emergent génère des applications web et mobiles avec une équipe d'agents IA. Ses limites quand le projet devient un produit, et l'alternative.
Squarespace soigne le design et la prise en main. Ses limites quand le site doit grandir ou changer de plateforme, et l'alternative.
Figma Make génère désormais des applications avec un back-office Payload. Ses limites au moment de l'écriture, et l'alternative.
Cet article vous a été utile ?
Écrit par L'équipe Hultra Studio. Parlons de votre projet : un premier échange suffit pour le cadrer.