Prototype ≠ production : le « ça marche » n'est pas fini

En quelques minutes, un assistant génère une fonctionnalité qui compile, s'exécute et « a l'air de marcher ». La démonstration est convaincante — et c'est précisément ce qui trompe. Car « ça marche sur ma machine », sur le chemin nominal, ne représente qu'une fraction de ce qu'exige la production. Tout ce que la démo n'a pas rencontré reste à faire : gérer les erreurs, valider les entrées, tenir les cas limites, la charge, la sécurité, garder des traces, borner les ressources, tester pour de vrai, rester maintenable. Le prototype généré est un point de départ, pas un livrable. Confondre « la démo tourne » avec « c'est fini », c'est expédier en production des systèmes fragiles. Le travail du développeur, aujourd'hui, c'est exactement le durcissement que la démo a sauté.

Un prototype qui tourne n'est pas un système fini

Commençons par rendre justice au prototype : il a une vraie valeur. Générer vite un rendu qui fonctionne permet de lever un doute de faisabilité, d'explorer une piste, de montrer une intention plutôt que de la décrire. Un prototype est un excellent prototype. Le problème n'est pas de le produire — c'est de le prendre pour autre chose que ce qu'il est. Un rendu qui passe le cas heureux prouve qu'un chemin fonctionne dans des conditions idéales ; il ne prouve rien sur ce qui arrive quand les conditions cessent d'être idéales. Or la production, par définition, est faite de conditions qui ne sont pas idéales.

Pour voir l'écart, il suffit de rappeler ce que « qualité d'un logiciel » recouvre vraiment. La norme internationale ISO/IEC 25010 — le modèle de qualité produit de référence en génie logiciel — ne réduit pas la qualité à « la fonction est là ». Elle la décompose en plusieurs caractéristiques, dont l'aptitude fonctionnelle n'est qu'une parmi d'autres : la fiabilité (tenir dans le temps et sous conditions réelles), la sécurité, l'efficacité de performance — définie comme le degré auquel un produit « accomplit ses fonctions dans les limites de temps et de débit spécifiées et fait un usage efficace des ressources » — et la maintenabilité. Un prototype qui « marche » satisfait la première case et laisse toutes les autres vides. « Prêt pour la production » veut dire au-delà de « ça tourne » : cela veut dire que ces dimensions-là, invisibles dans une démo, ont été traitées (Fig. 1).

Ce que le « ça marche » généré saute par défaut

Le piège n'est pas que l'assistant produise du mauvais code : c'est qu'il produise un code qui a l'air fini alors qu'il ne couvre que le cas nominal. Par défaut, une génération vise à satisfaire la demande telle qu'elle est formulée — « écris une fonction qui fait X » — et s'arrête quand X fonctionne sur l'exemple. Tout ce qui n'a pas été explicitement demandé, et que la démo ne rencontre pas, tend à rester dehors (Fig. 2). C'est une liste longue et connue : la gestion d'erreurs et la validation des entrées ; les cas limites — entrée vide, valeur négative, format inattendu, débordement ; la concurrence et le comportement sous charge ; les limites de ressources — mémoire, connexions, quotas ; l'observabilité — journaux, mesures, alertes — sans laquelle une panne en production est aveugle ; les modes de défaillance — que se passe-t-il quand la dépendance externe ne répond pas ; les tests qui éprouvent autre chose que l'exemple ; et la maintenabilité, pour que le code survive au prochain qui le touchera. Aucune de ces dimensions n'apparaît dans une démo réussie, parce qu'une démo réussie, par construction, ne les traverse pas.

La sécurité illustre bien ce défaut par omission — et le fait est mesuré, pas supposé. Une étude contrôlée présentée à la conférence ACM CCS 2023, Do Users Write More Insecure Code with AI Assistants? (Perry, Srivastava, Kumar, Boneh), a comparé des participants équipés d'un assistant de génération de code à un groupe témoin. Résultat : les participants ayant accès à l'assistant « ont écrit un code significativement moins sûr que ceux qui n'y avaient pas accès ». Le durcissement sécurité — échapper une entrée, éviter une injection, ne pas exposer un secret — fait partie de ce que le premier jet néglige quand personne ne le réclame. On retrouve exactement le raisonnement des tests à l'ère de l'IA : ce qui n'est pas éprouvé explicitement n'est pas couvert, aussi fluide que soit le rendu.

Pourquoi la fausse fin coûte cher — et comment durcir

Croire une démo sur parole n'est pas neutre : c'est reporter le travail au moment où il coûte le plus cher. Le rapport de la NASA Error Cost Escalation Through the Project Life Cycle (Stecklein, Dabney, Dick, Haskins, Lovell, Moroney, INCOSE 2004) rappelle un résultat d'ingénierie classique, dû à Barry Boehm : « trouver et corriger un problème logiciel après livraison peut coûter jusqu'à cent fois plus cher que de le trouver et le corriger au stade des exigences et de la conception initiale ». Un cas limite non traité, une entrée non validée, une panne non observée ne disparaissent pas parce que la démo les a masqués : ils resurgissent en production, là où le diagnostic est difficile et l'incident visible. Sauter le durcissement ne supprime pas son coût — cela le déplace vers le pire moment. C'est le même argument que celui de l'estimation à l'ère de l'IA : le durcissement est justement la part de la tâche qui ne se comprime pas, et l'oublier, c'est chiffrer une tâche qui n'existe pas.

À ce coût s'ajoute un facteur humain qui aggrave la fausse fin. Le profil « IA générative » du NIST (AI 600-1) le nomme : « les humains peuvent trop se fier aux systèmes d'IA générative […] un exemple de biais d'automatisation, ou de déférence excessive envers les systèmes automatisés ». La même étude CCS 2023 le confirme sous un angle troublant : les participants assistés « étaient plus enclins à croire qu'ils avaient écrit un code sûr » — alors qu'ils écrivaient l'inverse. La fluidité du rendu fabrique une confiance que le contenu ne mérite pas encore. D'où une règle de conduite simple : traitez « la démo tourne » comme un signal de départ, jamais comme une preuve d'achèvement. Le fait qu'un code s'exécute ne dit rien de sa robustesse.

Durcir, concrètement, c'est parcourir méthodiquement l'iceberg immergé. Éprouver les entrées : que fait le code sur une valeur vide, malformée, hostile ? Traiter les échecs : chaque appel qui peut rater doit avoir un comportement défini, pas une exception qui remonte à l'aveugle. Instrumenter : des journaux et des mesures pour que la production parle quand elle souffre. Éprouver la charge et la concurrence là où elles s'appliquent. Écrire des tests qui visent les cas limites, pas seulement l'exemple. Et relire pour la maintenabilité, car un code qu'on ne peut pas modifier sans risque est une dette. Une bonne part de ce travail se mène d'ailleurs très bien avec l'IA — à condition de la piloter pour ça : lui faire générer les cas limites qu'on n'a pas en tête, ou l'utiliser pour déboguer et confronter chaque hypothèse au comportement réel. L'outil qui a produit le prototype peut aider à le durcir ; encore faut-il le lui demander explicitement, parce qu'il ne le fait pas de lui-même.

Durcir le prototype, c'est le travail qui reste

Ce volet retrouve le fil rouge de la série et le rend tangible sur un geste quotidien : le métier glisse de produire vers vérifier. La génération de code a fait s'effondrer le coût du premier jet — et c'est une vraie avancée. Mais elle n'a pas touché à ce qui sépare un premier jet d'un système : la robustesse. Cette robustesse ne s'écrit pas toute seule parce qu'un modèle écrit vite ; elle se construit, dimension par dimension, par un travail de jugement et d'ingénierie que la démo ne fait qu'escamoter. Confondre « ça marche » et « c'est fini », c'est confondre la pointe de l'iceberg avec l'iceberg.

La bonne posture tient en une phrase : se servir de l'IA pour atteindre vite le prototype, puis assumer que tout le travail sérieux commence là. Le développeur n'est plus d'abord celui qui fait apparaître le code ; il est celui qui le rend digne de la production — celui qui éprouve, valide, instrumente et durcit ce qu'une génération a laissé au stade de la démonstration. C'est la posture de réviseur plutôt que producteur appliquée au cycle entier : la valeur n'est plus dans le rendu qui tourne, mais dans le système qui tient. La bonne question n'est jamais « est-ce que ça marche ? », mais « est-ce que ça tiendra quand ça ne se passera pas comme dans la démo ? ». Un prototype montre qu'une solution est possible. En faire un système, c'est le vrai métier — et c'est celui qui reste.