Votre prototype marche : c'est précisément là que le projet s'arrête
L'essentiel pour les décideurs
Le constat : 41 % seulement des prototypes d'IA générative atteignent la production, d'après l'enquête Gartner AI Mandates for the Enterprise. Fabriquer une maquette est devenu gratuit ; la mettre en service ne l'est pas.
L'enjeu chiffré : Gartner anticipe que les approches prompt-to-app portées par des développeurs métier multiplieront par 25 le nombre de défauts logiciels d'ici 2028. La vitesse sans chaîne de fabrication produit de la dette, pas des applications.
Ce qui change la donne : une chaîne de fabrication, la Forge, qui enveloppe l'interface déjà validée par le métier au lieu de la réécrire, y ajoute persistance, authentification et contrôles bloquants, et garde la mise en production comme décision humaine explicite.
La preuve interne : cinq applications en service en trois semaines, une quinzaine d'utilisateurs, périmètre en extension vers la finance, les RH et le reporting. Nous exploitons la chaîne avant de la proposer.
Près de six prototypes sur dix meurent après avoir convaincu
Il existe un moment très reconnaissable dans la vie d'un outil métier. La démonstration se passe bien, la salle est convaincue, quelqu'un demande quand est-ce qu'on l'utilise pour de vrai. Et là, la réponse honnête est : dans six mois, si on lance un projet.
Ce décalage s'est creusé. Produire une interface crédible en deux jours est devenu banal pour une équipe qui sait décrire ce qu'elle veut. Le reste n'a pas bougé d'un millimètre : il faut toujours savoir qui a le droit d'ouvrir l'outil, prévoir ce qui se passe quand deux personnes écrivent en même temps, décider où vivent les données le jour où elles ne sont plus celles d'une seule personne, et désigner celui qui reprendra le téléphone dans dix-huit mois. Nous avons rendu la fabrication gratuite et laissé la mise en service au même prix qu'avant.
Les chiffres disent l'écart. Selon l'enquête Gartner AI Mandates for the Enterprise, 41 % des prototypes d'IA générative franchissent la barrière de la production. Autrement dit, près de six initiatives sur dix meurent après avoir convaincu. Le fond métier était validé dans la plupart des cas. L'échec s'est joué sur la plomberie.
Une marche est tombée, l'autre n'a pas bougé
Le coût de fabrication s'est effondré, le coût de mise en service est resté le même. C'est tout l'écart de l'article : la deuxième marche n'a pas bougé d'un millimètre, et elle est désormais la seule.
Le coût de la mise en service n'a pas baissé, lui
La vague qui arrive vient des métiers. Gartner estimait que d'ici 2026, 80 % des utilisateurs d'outils de développement low-code se trouveraient en dehors des équipes informatiques, et que dans les grandes entreprises les développeurs métier seraient quatre fois plus nombreux que les développeurs professionnels. Ajoutez-y les assistants de codage conversationnels, et vous obtenez une population qui produit des applications sans avoir jamais eu à connaître un dépôt de code.
Je vois cette population tous les jours chez nos clients et dans nos propres équipes. Elle produit vite, elle produit juste sur le fond métier, et elle s'arrête toujours au même endroit. Les données vivent dans le stockage local du navigateur : rien n'est partagé, rien n'est sauvegardé côté serveur, personne ne s'authentifie. L'outil fonctionne pour son auteur, sur son poste, tant qu'il ne vide pas son cache.
La marche à franchir a un nom peu glorieux et un coût réel : reprendre ce qui existe pour en faire un logiciel exploitable. Historiquement, cette marche se franchissait en réécrivant tout, et c'est là que la valeur se perdait. L'interface validée par le métier, celle qui portait la connaissance du processus, disparaissait dans le projet de refonte. Le métier se désengageait, la version livrée ressemblait à autre chose, et l'outil finissait peu utilisé. C'est cette marche que nous avons outillée chez Keyrus, dans une chaîne que nous appelons la Forge. Avant d'y venir, il faut nommer précisément ce qui casse.
Ce qui bloque n'est jamais le modèle
La persistance arrive trop tard dans la réflexion. Un prototype garde ses données au plus près de son auteur, parce que c'est la voie la plus courte vers la démonstration. Le jour où deux personnes doivent saisir dans le même écran, il faut un serveur, une interface de programmation, une stratégie de conflit. C'est un changement de nature : l'outil passe d'un artefact personnel à un actif partagé, avec tout ce que cela implique de sauvegarde et de reprise.
La sécurité est traitée comme une couche de finition. Elle ne l'est jamais. Le rapport GenAI Code Security de Veracode, qui a testé plus de 100 modèles sur 80 tâches de développement, relève que 45 % du code généré introduit une vulnérabilité du top 10 de l'OWASP, et que le code produit par IA contient 2,74 fois plus de vulnérabilités que celui écrit par un humain. Le détail qui doit retenir l'attention d'un DSI : Java, langage de référence des applications d'entreprise, affiche un taux d'échec supérieur à 70 %.
Le volume de défauts croît plus vite que la capacité à les traiter. Dans ses prédictions 2026 pour l'ingénierie logicielle, Gartner anticipe que les approches prompt-to-app adoptées par les développeurs métier feront croître les défauts logiciels de 2 500 % d'ici 2028, au point de déclencher une crise de qualité et de fiabilité. Ce chiffre ne condamne pas la pratique. Il dit que la pratique sans garde-fous ne passe pas à l'échelle.
Personne ne sait qui exploite. Un outil qui tourne sur le poste de son auteur n'a ni astreinte, ni sauvegarde, ni procédure de reprise. Quand il devient critique pour un processus de facturation ou de planification, l'entreprise découvre qu'elle dépend d'un actif que sa DSI ne connaît pas. L'objet a changé de statut en cours de route : c'est du shadow IT avec une bonne interface.
La réécriture détruit l'adhésion. C'est le point le moins mesuré et le plus coûteux. Le métier a validé un écran parce qu'il correspondait à sa façon de travailler. Le refaire, même mieux, c'est repartir de zéro sur l'appropriation.
Les cinq points de rupture
Les cinq ruptures sont toutes sur la chaîne, aucune n'est dans l'outil. C'est ce qui rend le diagnostic actionnable : ce qui casse ne se corrige pas en changeant de modèle.
Ces cinq points ont un dénominateur commun : aucun ne relève de l'intelligence mise dans l'outil. Ils relèvent tous de la chaîne qui transforme un objet démontrable en objet exploitable. Cette chaîne existe, elle a un coût de construction, et c'est le seul endroit où l'écart se comble.
Où se situe la Forge dans le HOM™
Là où la Forge agit. Elle produit des modules homogènes : une seule façon de persister, de déployer et de superviser, et un stockage qu'on change par simple configuration sans toucher à l'interface. Elle fait de la mise en production une décision humaine explicite, encadrée par un contrôle qualité bloquant et par le gel automatique de toute livraison sur vulnérabilité critique. Enfin, elle sert d'abord des outils de pilotage, suivi d'avant-vente, suivi de chantiers, tableaux de bord, là où l'intelligence change réellement une décision.
La Forge
La Forge n'est pas née d'une feuille de route produit. Elle est née d'une facture que nous payions tous les mois.
Nos équipes d'avant-vente, de delivery et de pilotage maquettent l'outil idéal en trois jours. Puis rien. L'outil ne quitte pas le poste de son auteur, aucun collègue ne peut y saisir quoi que ce soit, et la seule voie connue pour le rendre utilisable coûtait un projet et deux trimestres. Fabrication gratuite, mise en service au tarif d'avant. L'écart se règle en frustration côté métier et en shadow IT côté DSI.
Le cas fondateur : l'outil de suivi avant-vente PNL interne
Avant. Un écran de suivi d'avant-vente, marge calculée juste, adopté en quelques jours. Et strictement personnel : la donnée vivait dans le navigateur de son auteur, invisible pour ses collègues, perdue au premier cache vidé.
Après. Le même écran, au pixel, mais partagé par une quinzaine d'utilisateurs : directeurs de projet, experts, chefs de projet. L'état est sauvegardé côté serveur, l'accès passe par l'authentification d'entreprise, et personne n'a eu à ouvrir un dépôt de code. Nous n'avons rien réécrit, nous avons enveloppé l'écran que le métier avait déjà adopté.
La réponse orthodoxe consistait à le refaire proprement. Nous avons décidé de ne rien refaire et de construire autour. La Forge n'est que cela : la couche qui manque entre un écran que le métier a adopté et un actif que l'entreprise sait exploiter.
Envelopper l'interface validée, au lieu de la réécrire
Réécrire ou envelopper
Le même écran, deux destins. À gauche, il disparaît dans la refonte ; à droite, il est au centre et ce sont les couches manquantes qui viennent autour. Les deux écrans dessinés à l'identique sont le point : rien n'a été refait.
Une commande, et la page devient une application. Elle est servie telle quelle par un serveur d'application standard, une interface de programmation minimale prend en charge l'état partagé, la sécurité HTTP est posée, l'infrastructure est décrite. Le métier ouvre l'application déployée et retrouve son écran au pixel. Ce détail apparemment cosmétique décide de l'adhésion : une refonte, même meilleure, rend au métier un outil qui n'est plus le sien. C'est le mode d'échec le plus coûteux et le moins mesuré des projets d'outillage.
Le partage tient dans un contrat pauvre, et c'est voulu. Un document, deux opérations pour le lire et le remplacer, une abstraction de stockage à trois implémentations : mémoire pour démontrer, fichier pour développer, stockage managé en service. On en change par configuration, jamais par migration. Le conflit d'écriture se règle au dernier qui écrit. Sur un usage séquentiel c'est le bon niveau d'effort ; faire mieux aurait coûté un chantier de verrouillage que personne n'avait demandé.
Deux barrières tiennent la sortie. Avant toute livraison, un contrôle qualité bloquant, analyse statique de sécurité et dépendances vulnérables comprises : une faille critique gèle la production jusqu'à résolution, sans dérogation d'urgence. En service, authentification d'entreprise obligatoire, filtrage par groupe d'annuaire, accès restreint au réseau interne. Rien de tout cela n'est joignable depuis l'Internet ouvert.
Livrer sans connaître Git, et ce que ça débloque
Une demande, une journée, un seul geste humain
Entre la demande du matin et la production, deux barrières et une seule main humaine. Le contrôle qualité renvoie la livraison sans négociation possible ; la promotion, elle, ne s'automatise pas.
Un exemple. Un directeur de projet demande le matin une évolution de son chiffrage : une ligne de marge à ajouter, un total à recalculer. Il décrit le changement en français, pas en langage d'ingénieur, et l'obtient en service dans la journée. Il n'a nommé ni branche, ni environnement, ni demande de fusion, et ne sait toujours pas dans quel dépôt vit son application. La promotion en production, elle, reste un geste humain, daté et attribuable.
Côté chaîne, le travail est le même qu'avant, il a seulement changé de main. L'assistant identifie l'application concernée, isole le changement, gère la fusion, déploie sur l'environnement d'aperçu, et rend un résumé en langage métier.
Ce que nous avons retiré du parcours n'est pas du travail de développement. C'est du vocabulaire. Tant que la voie officielle impose un lexique d'ingénieur, elle perd contre le navigateur, qui ne demande rien à personne. Une DSI ne reprend pas la main en interdisant le contournement. Elle la reprend en le rendant inutile.
Un générateur unique, cinq archétypes d'applications
Un seul moule, cinq familles
Le socle partagé est le rendement. Cinq familles suffisent à couvrir les besoins, et c'est parce qu'elles sortent du même moule qu'on peut en tenir cinquante sans monter cinquante équipes.
Traiter chaque demande comme un cas particulier, c'est un parc ingérable à la quinzième application. Nous avons pris l'autre pari : un générateur unique, cinq archétypes. Saisie partagée, support projetable édité en place, déclaratif adossé à des indicateurs relus en direct, tableau de bord requêté sur l'entrepôt de données côté serveur, portail multi-pages sous un même toit. Qualifier un besoin revient à le rattacher à une famille connue, ce qui rend le délai annonçable avant d'avoir commencé.
Le rendement n'arrive qu'avec le volume. Même moule, donc même architecture, même persistance, même chaîne de qualité : qui connaît une application les connaît toutes. Tenir cinquante outils sans monter cinquante équipes, c'est la seule promesse qui compte à la fin.
La Forge tourne d'abord sur nos propres outils. L'outil de suivi avant-vente PNL est passé le premier, le delivery et le pilotage ont suivi. Nous tenions à payer l'exploitation, les astreintes et les reprises, avant d'aller vendre la chaîne à quelqu'un d'autre.
Concrètement, à l'heure où j'écris : cinq applications en service, une chaîne en production depuis trois semaines, utilisée par une quinzaine de personnes, directeurs de projet, experts et chefs de projet. Le périmètre s'élargit déjà vers la finance, les RH et le reporting. Le premier outil passé par la chaîne est notre outil de suivi avant-vente PNL interne : prototypé en trois jours, testé, mis en production, puis amélioré en continu. Je ne juge pas encore cette chaîne sur sa centième mise en production. Je constate qu'elle a mis cinq outils en service là où, il y a un mois, il n'y en avait aucun, et que je les exploite moi-même avant d'aller les proposer.
Cinq règles pour industrialiser sans casser l'adhésion
L'interface validée est l'enveloppe, pas un brouillon. Tout ce qui a été accepté par le métier doit survivre au passage en production. C'est la condition de l'adhésion, et c'est aussi une garantie de réversibilité : si la chaîne change, l'écran reste.
La mise en production est une décision, jamais un automatisme. Le déploiement peut être entièrement outillé, la promotion doit rester un geste humain daté et attribuable. C'est ce qui distingue une chaîne gouvernée d'une fuite en avant, et c'est la traduction opérationnelle du principe Human in Command.
La sécurité est bloquante ou décorative. Un contrôle qui alerte sans arrêter la livraison finit ignoré. Au vu des taux de vulnérabilité observés sur le code généré, le seul dispositif tenable est celui qui gèle la mise en production sur une vulnérabilité critique, sans exception négociable dans l'urgence.
Un seul générateur, quelques archétypes. La tentation est de traiter chaque application comme un cas particulier. C'est ce qui rend un parc ingérable au bout de la quinzième. Ramener les besoins à un petit nombre de familles permet de faire évoluer cinquante applications d'un seul geste. Cinq archétypes couvrent aujourd'hui l'essentiel de ce que produisent nos équipes.
Le stockage est une décision réversible. Commencer en mémoire, passer à un fichier, puis à un stockage managé selon l'usage réel. Ce qui compte est que ce choix soit isolé derrière une interface unique, pour ne jamais devenir un projet de migration.
Ces principes rejoignent une évolution de fond du métier de développeur. Gartner estime que d'ici fin 2026, 75 % des développeurs passeront plus de temps à orchestrer et à architecturer qu'à écrire du code. La valeur se déplace vers la chaîne, pas vers la ligne.
Trois routes, un seul besoin métier
Le shadow IT ne se combat pas, il se démode. Tant que la voie officielle est la plus longue, elle perd. La chaîne ne gagne pas parce qu'elle est gouvernée, elle gagne parce qu'elle est aussi la plus courte.
Questions essentielles
Qu'est-ce qui empêche concrètement un prototype d'IA de passer en production ?
Rarement le modèle ou la fonctionnalité. Ce sont la persistance des données, l'authentification, la gestion des accès et l'absence de responsable d'exploitation. L'enquête Gartner AI Mandates situe à 41 % la part des prototypes d'IA générative qui atteignent la production, et l'essentiel des abandons se joue sur ces sujets d'exploitation plutôt que sur la pertinence métier.
Le code généré par IA est-il assez sûr pour une application d'entreprise ?
Pas sans contrôles automatisés et bloquants. Veracode mesure que 45 % du code généré introduit une vulnérabilité du top 10 de l'OWASP, avec un taux d'échec supérieur à 70 % en Java. Le code généré devient acceptable en production quand une chaîne l'analyse systématiquement et refuse la livraison sur vulnérabilité critique.
Faut-il réécrire une maquette métier pour la mettre en production ?
Non, et c'est même contre-productif. Réécrire fait perdre l'adhésion du métier, qui a validé un écran correspondant à sa façon de travailler. L'approche consiste à envelopper l'interface existante dans une chaîne qui lui ajoute serveur, persistance et authentification, sans toucher à ce qui a été accepté.
Comment éviter que les applications créées par les métiers deviennent du shadow IT ?
En leur offrant une voie officielle plus rapide que la voie officieuse. Tant que passer par la DSI coûte six mois et que le contournement en coûte trois, le shadow IT gagne. Une chaîne de fabrication qui met en production en quelques jours, avec authentification d'entreprise et supervision, supprime l'intérêt du contournement.
Nous avons déjà une plateforme low-code, pourquoi une chaîne de plus ?
Parce qu'elles ne répondent pas à la même question. Une plateforme low-code impose son outil de création : ce qui n'y est pas né n'y entre pas, et une maquette produite par un assistant conversationnel reste dehors. Une chaîne de fabrication entre par l'autre bout, elle prend l'interface là où elle a été écrite et lui ajoute serveur, persistance, authentification et supervision. Les deux coexistent sans se recouvrir. La question à poser à un fournisseur n'est pas ce qu'il sait générer, mais ce qu'il sait reprendre.
Peut-on laisser une IA déployer en production toute seule ?
Techniquement oui, et c'est précisément ce qu'il faut refuser. L'agent peut préparer le changement, ouvrir la demande de fusion et déployer sur un environnement d'aperçu. La promotion en production reste une décision humaine explicite, tracée et attribuable, sans quoi il devient impossible de répondre à la question de savoir qui a décidé quoi.
Industrialiser est le seul avantage qui ne se copie pas
Fabriquer une interface convaincante est à la portée de tout le monde, y compris de vos concurrents, y compris cette semaine. Ce qui se copie difficilement, c'est la capacité à mettre en service, à exploiter et à maintenir cinquante applications utiles avec la même exigence de sécurité et le même coût marginal.
C'est le sens de notre positionnement d'architecte d'intelligence : nous ne vendons pas la démonstration, nous construisons la couche qui la rend opérable. La Forge est notre propre application de ce principe. Nous l'avons construite pour nos équipes d'avant-vente, de delivery et de pilotage, et nous l'exploitons avant de la proposer, parce qu'une chaîne de fabrication ne se juge pas sur sa première mise en production mais sur la centième. Une intelligence qui reste dans un navigateur ne produit aucune performance.
Vous avez un outil métier qui fonctionne et qui ne sort pas du poste de son auteur ? Faites-le évaluer par nos équipes Delivery : nous qualifions en une demi-journée son archétype, c'est-à-dire laquelle de nos cinq familles il rejoint, son besoin de persistance et son niveau d'exposition, et nous vous disons ce que coûte réellement sa mise en service.
Patricio Touchard est Tech Lead Expert chez Keyrus. Il conçoit et opère la Forge, la chaîne de fabrication qui transforme les prototypes métier en applications d'entreprise déployées et supervisées.
Sources et références
Gartner, AI Maturity Matters: Proportion of AI and GenAI Prototypes Making It Into Production : https://www.gartner.com/en/documents/6587902
Gartner, redicts 2026: AI Potential and Risks Emerge in Software Engineering Technologies : https://www.gartner.com/en/documents/7239930
Synthèse des prédictions Gartner 2026 sur la dette de code généré : https://www.armorcode.com/report/gartner-predicts-2026-ai-potential-and-risks-emerge-in-software-engineering-technologies
Veracode, 2025 GenAI Code Security Report : https://www.veracode.com/resources/analyst-reports/2025-genai-code-security-report/
Veracode, Spring 2026 GenAI Code Security Update : https://www.veracode.com/blog/spring-2026-genai-code-security/
Cloud Security Alliance,Vibe Coding's Security Debt: The AI-Generated CVE Surge : https://labs.cloudsecurityalliance.org/research/csa-research-note-ai-generated-code-vulnerability-surge-2026/
Gartner, prévisions du marché des technologies de développement low-code : https://www.gartner.com/en/newsroom/press-releases/2022-12-13-gartner-forecasts-worldwide-low-code-development-technologies-market-to-grow-20-percent-in-2023
Help Net Security, synthèse des résultats Veracode sur la sécurité du code généré : https://www.helpnetsecurity.com/2025/08/07/create-ai-code-security-risks/
OWASP Top 10, référentiel des risques applicatifs : https://owasp.org/www-project-top-ten/