Prototype généré par IA : les contrôles avant la mise en production

Ce qu'est un prototype généré par IA

Un prototype généré par IA est une application obtenue en quelques heures à partir de consignes en langage naturel, à l'aide d'un outil de génération de code comme Lovable, Bolt, v0 ou Cursor. Il montre un parcours qui fonctionne devant un public choisi. Une application prête pour la production tient sur trois choses de plus : elle résiste aux usages que personne n'avait prévus, elle protège les données qu'on lui confie, et quelqu'un d'autre que son auteur sait la reprendre dans six mois.

La différence n'est pas une question de qualité de code. Elle est de nature. Un prototype répond à la question « est-ce que ça pourrait marcher ? ». Une application en production répond à une question beaucoup plus dure : « qu'est-ce qui se passe quand ça ne marche pas ? ». Personne n'écrit cette seconde réponse à la place de l'équipe qui exploitera l'outil.

Je vois la même scène se répéter depuis quelques mois chez mes clients. Un dirigeant, un responsable métier ou un alternant a passé deux soirées sur un de ces outils. Il en ressort un écran de connexion, une liste filtrable, un formulaire, parfois un tableau de bord. La démonstration est convaincante. La question qui suit tombe toujours : on ouvre ça aux clients lundi ? Ma réponse ne commence ni par oui ni par non, elle commence par une liste de contrôles.

Ce que ces outils apportent vraiment

Je ne fais pas partie de ceux qui les balaient d'un revers de main. Ils rendent trois services que rien ne rendait aussi bien il y a deux ans.

• Ils font trancher une idée avant d'engager un budget. Un comité qui hésite entre deux directions se décide en dix minutes devant un parcours cliquable, alors qu'il aurait passé trois réunions sur une note d'intention.
• Ils remplacent des pages de description par une démonstration. Le métier voit ce qu'il aura, et surtout ce qu'il n'aura pas. Les malentendus qui coûtent le plus cher en développement se règlent à ce moment-là.
• Ils font gagner des semaines de maquettage. Là où il fallait un zoning, des écrans, puis un prototype cliquable, un premier jet arrive en une journée et se retouche à la demande.

C'est exactement l'usage que je recommande : en amont, pour lever un doute. Je m'en sers pour matérialiser une idée pendant une phase de cadrage, au même titre qu'un croquis d'écran. Cette place, en tête de projet, est décrite dans mon guide sur le MVP et le premier périmètre utile, et l'arbitrage entre plateforme toute faite et développement figure dans no-code ou sur-mesure.

Ce que le prototype ne dit pas encore

Ce qui suit n'est pas une liste de défauts imputables à tel ou tel outil. Ces produits évoluent vite, et ce qui manque dans une version peut être couvert dans la suivante. Ce sont des points à ouvrir et à vérifier sur votre prototype, un par un, avant toute décision.

• L'authentification et la gestion des droits. Un écran de connexion existe presque toujours. La vraie question est de savoir si un utilisateur connecté peut atteindre les données d'un autre en modifiant une adresse ou une requête. Testez-le explicitement, avec deux comptes.
• La validation des données côté serveur. Les contrôles visibles dans le formulaire ne protègent rien : ils s'enlèvent en trois clics dans un navigateur. Regardez si les mêmes règles sont rejouées côté serveur avant l'enregistrement.
• Les secrets et les clés d'API. Une clé de service de paiement, d'envoi de courriel ou de modèle de langage qui se retrouve dans le code livré au navigateur est utilisable par n'importe qui. C'est le point que je regarde en premier, parce qu'il se vérifie en une minute et qu'il coûte cher.
• Les sauvegardes et la restauration. Avoir une sauvegarde ne sert à rien tant que personne n'a restauré une base à partir d'elle. Demandez la fréquence, la durée de rétention, et le temps qu'a pris le dernier essai de restauration.
• La montée en charge. Un prototype se comporte bien avec dix enregistrements et trois utilisateurs. Vérifiez son comportement avec le volume réel que vous attendez la première année, et non avec le jeu de démonstration.
• Le RGPD, dès qu'il y a des données personnelles. Base légale du traitement, information des personnes, durée de conservation, localisation de l'hébergement, sous-traitants, droit d'accès et d'effacement. Ces obligations existent indépendamment de la façon dont le code a été produit.
• L'accessibilité. Contraste, navigation au clavier, alternatives textuelles, structure des titres. Un générateur produit du markup plausible, pas une conformité vérifiée.
• La dette de dépendances. Listez les bibliothèques embarquées, leur version et leur licence. Une dépendance abandonnée ou une licence incompatible avec un usage commercial se découvre bien mieux avant la mise en ligne qu'après.
• Les tests. Sans jeu de tests automatisés, la première correction en casse une autre et personne ne s'en aperçoit. C'est ce qui rend la maintenance imprévisible, sujet que je détaille dans la maintenance applicative.
• La propriété et la portabilité. Pouvez-vous exporter la totalité du code, l'héberger ailleurs, et le confier à un développeur tiers ? Les conditions d'utilisation de l'outil répondent à ces trois questions, et elles seules.

Les dix contrôles avant la mise en production

Avant d'ouvrir un prototype généré par IA à de vrais utilisateurs, dix contrôles suffisent à savoir où vous en êtes. Chacun se répond par oui, par non, ou par « personne ne sait », et cette troisième réponse compte comme un non.

• Deux comptes utilisateurs distincts ont été créés, et aucun des deux n'accède aux données de l'autre.
• Les règles de saisie sont rejouées côté serveur, et pas seulement affichées dans le formulaire.
• Aucune clé d'API ni aucun mot de passe ne figure dans le code envoyé au navigateur ni dans l'historique du dépôt.
• Une sauvegarde a été restaurée pour de bon, sur un environnement séparé, et la durée de l'opération est connue.
• L'application a été essayée avec le volume de données attendu à douze mois.
• Le traitement des données personnelles est décrit : finalité, base légale, durée de conservation, hébergeur, sous-traitants.
• Un parcours complet a été effectué au clavier seul, et les images porteuses de sens ont une alternative textuelle.
• La liste des dépendances, de leurs versions et de leurs licences est établie, et aucune n'est abandonnée.
• Un jeu de tests automatisés couvre au minimum les parcours critiques, connexion et enregistrement compris.
• Le code est exportable, hébergeable ailleurs, et modifiable par un tiers sans l'accord de l'éditeur de l'outil.

Faites passer cette liste par quelqu'un qui n'a pas construit le prototype. L'auteur d'un prototype coche naturellement les cases qu'il a en tête, pas celles qu'il a oubliées. C'est la même logique qu'une recette menée par une personne extérieure à la réalisation.

Les trois décisions possibles

Face à un prototype généré par IA, il n'y a que trois issues raisonnables : le jeter et repartir sur une base propre, le reprendre et le durcir, ou le garder comme outil interne sans jamais l'ouvrir à l'extérieur. Le choix se fait sur la valeur de l'usage, la sensibilité des données et l'état du code, pas sur l'attachement de celui qui l'a produit.

La première colonne surprend souvent, alors qu'elle est fréquemment la bonne. Jeter un prototype n'annule pas sa valeur : il a servi à décider, et il a coûté deux jours. Le garder par principe, en revanche, engage des années de maintenance sur des fondations que personne n'a choisies. Cette question de la base de départ est la même que celle que je traite dans la reprise d'un projet applicatif existant.

Cadrer la suite avec un prestataire

Si la décision est de durcir, ne demandez pas « un devis pour finaliser l'application ». Cette formulation produit des propositions qui vont du simple au quintuple, parce que chacun devine un périmètre différent. Découpez plutôt en deux temps.

• Un audit court et payé, livré par écrit. Vous confiez le prototype, vous demandez un rapport sur les dix points ci-dessus, une estimation de l'effort de remise à niveau et un avis franc sur le fait de garder ou non la base. Un prestataire qui accepte de vous dire de tout jeter mérite votre attention.
• Un chantier de mise en production, chiffré sur le rapport. Il porte sur les exigences que le prototype n'a jamais eu à satisfaire : sécurité, sauvegardes, surveillance, tests, procédure de déploiement, réversibilité. C'est la matière d'une vraie mise en production.

Demandez le rapport d'audit à deux prestataires plutôt qu'un seul, et comparez leurs écarts d'appréciation autant que leurs prix. Les critères de sélection valent ici comme ailleurs, je les détaille dans choisir un prestataire de développement. Enfin, ne laissez pas le sujet flotter entre le métier et la direction technique : un prototype sans propriétaire nommé finit en production par accident, ce qui est la pire des trois issues. Sur la place de ces outils dans une organisation, mon guide IA et automatisation pose le cadre général.

Sur le financement, une précision utile avant de monter un dossier : les dispositifs publics cofinancent des diagnostics et des accompagnements, pas les licences ni les abonnements que consomme le prototype. Les conditions d'accès, les montants et les aides éteintes sont détaillés dans la page sur ce que couvrent réellement les aides publiques.

À propos de l'auteur

Laurent Tulpan

Directeur de projet digital senior, ancien développeur et expert SEO depuis 2005. Il expertise des applications avant reprise et cadre la mise en production de projets menés pour des grands comptes et des PME (TF1, SFR, Orange, SNCF), du côté du client. Découvrir son approche.