Aller au contenu
SwankyForge
SwankyForge
Toutes les analyses
Article10 min de lecture

Un prototype en vibe coding coûte un week-end. La production coûte le reste.

L'IA a rendu les prototypes presque gratuits, mais le travail qui transforme une démo en système sur lequel on peut compter n'a pas diminué : un prototype doit donc être budgété comme une spécification, pas comme l'essentiel du produit.

En novembre 2025, le Collins Dictionary a désigné « vibe coding » mot de l'année et l'a défini comme le fait d'utiliser l'IA, pilotée en langage naturel, pour aider à écrire du code. L'expression s'est imposée parce que l'expérience est réelle. On décrit une application, on accepte ce que le modèle écrit, et un écran fonctionne dès le dimanche soir. Un fondateur peut désormais montrer une démo à des clients avant d'embaucher un ingénieur.

Ce qui n'est pas devenu moins cher, c'est la partie qui rend un logiciel fiable. Dans le Stack Overflow Developer Survey 2025, 66 % des développeurs ont cité « des solutions IA presque justes, mais pas tout à fait » comme leur principale frustration avec les outils IA, et 45 % ont déclaré que déboguer du code généré par IA prend plus de temps. Un prototype est l'endroit où le presque juste suffit. La production est l'endroit où il ne suffit pas.

Cette note liste ce que la production ajoute à un prototype, propose une répartition approximative de l'effort et suggère comment le responsable du budget devrait traiter la démo qu'on vient de lui montrer.

Le gain de vitesse est réel, et toujours pas mesuré

La mesure la plus rigoureuse de la vitesse de développement avec l'IA vient de METR, une organisation de recherche à but non lucratif. Son essai randomisé de 2025 a montré que des développeurs open source expérimentés mettaient 19 % de temps en plus sur les tâches lorsque l'IA était autorisée, avec un intervalle de confiance de +2 % à +39 %.

Le 24 février 2026, METR a publié une suite : 57 développeurs, 143 dépôts, plus de 800 tâches, menée à partir d'août 2025. Sur la même échelle de variation du temps, où le résultat de 2025 était de +19 %, les nouvelles estimations ponctuelles sont de -18 % pour les développeurs revenant de la première étude (intervalle de -38 % à +9 %) et de -4 % pour les développeurs nouvellement recrutés (intervalle de -15 % à +9 %). Les deux estimations ponctuelles penchent désormais vers un gain de temps grâce à l'IA. Les deux intervalles incluent zéro.

METR qualifie lui-même les nouvelles données de signal peu fiable. Entre 30 % et 50 % des développeurs ont dit avoir choisi de ne pas soumettre certaines tâches parce qu'ils ne voulaient pas les faire sans IA. Les tâches où l'IA aide le plus manquent donc dans l'échantillon, et METR estime que le vrai gain est probablement plus important que son estimation.

Pour un acheteur, la conclusion est étroite. L'IA accélère une partie du développement, d'une ampleur que des chercheurs rigoureux n'ont pas réussi à cerner. Elle ne change pas ce dont un système a besoin avant que des gens puissent s'y fier.

Ce qu'un prototype prouve, et ce qu'il ne prouve pas

Un prototype de week-end prouve trois choses utiles : l'idée fonctionne sur les entrées que quelqu'un a essayées, l'interface a du sens pour les personnes qui l'ont vue, et quelqu'un en veut.

Il ne prouve pas que le système fonctionne sur des entrées que personne n'a essayées, qu'il fonctionne pour deux cents personnes en même temps, qu'il montre à chacun uniquement ce qu'il a le droit de voir, qu'il coûte ce que vous pensez par mois, ni que quelqu'un saura le réparer quand il tombe en panne la nuit. Ce sont les questions auxquelles répond la production.

Il y a une deuxième différence, facile à manquer. Un prototype est jugé par la personne qui l'a construit, le jour où il a été construit, sur des entrées qu'elle a choisies. Un système de production est jugé par des personnes qui n'ont jamais vu la démo, des mois plus tard, sur des données qui n'existaient pas quand le code a été écrit. L'essentiel du travail du tableau suivant existe pour que ce second jugement se passe bien.

Ce qu'ajoute la production

Les parts ci-dessous sont une répartition illustrative pour un outil LLM interne, comme un copilote de recherche documentaire, qui passe d'un prototype fonctionnel à quelques centaines d'utilisateurs quotidiens. Ce sont des opinions de planification, pas des mesures. Ajustez les poids à votre cas ; c'est la forme qui compte.

Poste de travail Ce que cela signifie Sans lui Part illustrative
Logique centrale Ce que le prototype montre déjà Pas de produit 20 %
Contrats de données et pipelines Contrôles de schéma sur chaque flux entrant ; chargements planifiés et idempotents Un export en amont change et les réponses se dégradent sans erreur 15 %
Jeu d'évaluation et seuils de qualité De vraies questions avec les réponses attendues, rejouées à chaque changement de prompt ou de modèle Personne ne peut dire si un changement a amélioré ou dégradé les choses 12 %
Authentification et permissions Single sign-on ; règles d'accès appliquées au moment du retrieval Des employés voient des documents qu'ils ne devraient pas voir 8 %
Validation des entrées et gestion des erreurs Limites de taille et de format ; traitement du texte hostile dans les fichiers importés et les documents récupérés Un fichier étrange fait tomber le service ou détourne le modèle 8 %
Monitoring et alertes Latence, taux d'erreur, coût par requête, taux de retrieval vide, retours utilisateurs Les problèmes sont signalés par les utilisateurs, des jours plus tard 8 %
Revue de sécurité et corrections Secrets, dépendances, données envoyées à des API tierces Une clé qui fuite ou une violation dans le traitement des données 8 %
Astreinte et runbooks Un responsable nommé et des étapes écrites pour les pannes courantes La seule personne qui sait est en vacances 7 %
Rollback et processus de mise en production Prompts, modèles et index versionnés ; un retour à la dernière bonne version Une mauvaise version reste en ligne pendant que quelqu'un la débogue 5 %
Documentation et passation Comment cela fonctionne, comment le modifier, comment l'exploiter Le système ne peut pas survivre à son auteur 5 %
Plafonds de coût Quotas par utilisateur, limites de tokens, coupe-circuit sur les dépenses Une boucle ou un gros utilisateur produit une facture surprise 4 %

La première ligne est le prototype. Dans cette répartition, il représente un cinquième du travail. Les quatre autres cinquièmes sont invisibles dans une démo, et c'est pourquoi une démo est un si mauvais guide pour un budget.

Pour les ingénieurs : où passe le temps

Quelques lignes méritent plus de détails, parce que c'est là que les estimations se trompent généralement.

Les permissions se placent dans le retrieval, pas dans la réponse. Dans un système de génération augmentée par la recherche, le contrôle d'accès doit filtrer les documents avant qu'ils n'atteignent le modèle. Filtrer après la génération ne fonctionne pas : le modèle a déjà lu le texte restreint et peut le paraphraser. Cela signifie que l'index porte des métadonnées d'accès, qu'il reste synchronisé avec le système source et que quelqu'un le teste avec des comptes aux droits différents.

Le jeu d'évaluation est la spécification sous forme exécutable. C'est un fichier versionné d'entrées réelles avec les sorties attendues ou des règles de notation, exécuté en CI à chaque changement de prompts, de modèles, de découpage ou de paramètres de retrieval. Le construire signifie s'asseoir avec les personnes qui utiliseront le système et écrire ce qu'est une bonne réponse. C'est lent, et aucun assistant ne peut le faire à votre place, parce que la connaissance est du côté des utilisateurs.

La validation des entrées inclut désormais du texte qui attaque le modèle. Un document de l'index peut contenir des instructions. Les fichiers importés peuvent être énormes, vides, des images scannées ou dans le mauvais encodage. Chaque cas demande un comportement défini et un test.

Le rollback exige que tout soit versionné ensemble. Une version, c'est un prompt, une version de modèle, une construction d'index et du code. Si seul le code est dans git, revenir en arrière sur le code ne fait pas revenir en arrière le comportement.

Les plafonds de coût sont une fonctionnalité de production. Un prototype a un utilisateur. Un système de production en a quelques centaines, plus des scripts et des relances. Des quotas par utilisateur, un nombre maximal de tokens et une alerte sur la dépense quotidienne sont peu coûteux à construire et évitent la mauvaise surprise la plus courante.

Comment traiter un prototype si vous tenez le budget

Traitez-le comme une spécification. Un prototype fonctionnel est l'expression la plus claire de ce que vous voulez que la plupart des projets obtiennent jamais. Remettez-le aux ingénieurs avec la liste des entrées sur lesquelles il a été essayé et les cas où il a échoué.

Ne le traitez pas comme 80 % du produit. Si un devis est faible parce que le prototype existe, demandez quelles lignes du tableau ci-dessus il couvre. Si la réponse est seulement la première, le devis porte sur un second prototype.

Utilisez-le pour tester la demande avant de financer la production. Mettez-le entre les mains des utilisateurs visés pendant deux semaines. S'ils n'y reviennent pas, vous avez économisé le budget de production, ce qui est la chose la plus utile qu'un prototype puisse faire.

Quand jeter le prototype

Réécrivez plutôt que d'étendre lorsqu'au moins l'une de ces conditions est vraie :

  • des secrets se trouvent dans le code ou dans l'historique du dépôt ;
  • les données sont atteintes via le compte personnel ou la clé d'API personnelle de quelqu'un ;
  • l'interface, la logique et l'accès aux données sont mélangés, si bien que les permissions ne peuvent pas être appliquées en un seul endroit ;
  • personne ne peut expliquer comment une réponse donnée a été produite ;
  • il tourne sur un outil de création hébergé qui ne peut pas être déployé dans votre environnement ni respecter vos règles sur les données ;
  • la logique est longue et n'a pas de tests.

Gardez-le lorsque la logique centrale est courte, lisible et séparable, que quelques tests existent déjà et que le flux de données ressemble à celui de la production.

Jeter du code coûte moins qu'il n'y paraît. Le prototype a déjà fait son travail : les décisions sont prises, les exemples sont collectés, l'interface a été essayée. Les prompts, les exemples d'entrées et les captures d'écran survivent généralement à une réécriture, même quand le code n'y survit pas.

À quoi ressemble l'écart en argent

Nos propres fourchettes de prix publiées montrent le même rapport. Une preuve de concept coûte 14k–38k € sur 4–7 semaines. Un développement de production coûte 45k–120k € sur 10–20 semaines. Aux deux extrémités de la fourchette, la production vaut environ trois fois la preuve de concept : 45 / 14 ≈ 3,2 et 120 / 38 ≈ 3,2. Ce multiple, c'est le coût des lignes du tableau autres que la première. Nous livrons le monitoring et le rollback avant la passation pour la même raison : c'est ce qui permet à un client d'exploiter le système sans nous.

Si vous avez déjà un prototype et voulez savoir quelles lignes il couvre, le teardown gratuit est une première vérification en six questions, et un court cadrage payant y répond entièrement. La même liste s'applique aux copilotes documentaires internes, où les permissions et le jeu d'évaluation prennent généralement le plus de temps.

Sources

Un processus vous coûte trop cher ?

Parlez-nous-en. Le premier appel est gratuit, et si l'IA n'est pas la réponse, nous le disons.

Discuter de votre tâche