19/7/2026
Selon le sondage Stack Overflow Developer, 66 % des professionnels constatent que l'IA livre un code « presque correct, mais pas tout à fait ». Pour une direction financière, cette phrase mérite d'être lue deux fois. Elle signifie qu'une technologie qui réduit drastiquement les délais de développement peut livrer, une fois sur trois, un code exigeant une reprise avant mise en production. Dans une banque, où chaque ligne de code touche potentiellement des flux de paiement, des données clients ou des obligations déclaratives, « presque correct » n’est pas un manque de qualité : c'est un risque opérationnel.
La pratique qui a popularisé cette productivité porte un nom : le Vibe Coding, c'est-à-dire le développement par dialogue libre avec un modèle d'IA, sans spécification formelle préalable. Elle excelle pour produire un prototype en quelques heures. Elle échoue structurellement à produire une application prête pour la production, pour des raisons qui tiennent à la nature même des LLMs et qu'un dirigeant doit prendre en compte avant d'arbitrer le moindre budget. Cet article expose ces raisons, présente le cadre qui les neutralise, le Spec-Driven Development, puis propose un protocole qui en organise l'adoption : nous l’appelons VISP (Vibe Industrialization Spec Pipeline). Le mot pipeline en dit la forme - une chaîne outillée où chaque phase alimente la suivante - ici trois phases, gouvernées par un rôle pivot, l'Augmented BA.
Quatre des caractéristiques des LLMs méritent d'être rappelées, car elles conditionnent directement la gouvernance de tout projet bancaire faisant appel à ces modèles.
La première est le non-déterminisme. Une même requête peut produire deux réponses différentes d'une exécution à l'autre. Pour un Tech Lead, cela impose des tests automatisés systématiques puisque rien ne garantit la reproductibilité d'une génération. Pour un Chief Risk Officer, cela signifie que l'audit de conformité ponctuel perd sa valeur de garantie permanente, imposant le basculement vers le contrôle continu, conforme aux exigences de résilience opérationnelle posées par DORA.
La deuxième est l'hallucination. Le modèle produit avec la même assurance une information exacte et une information inventée, car il optimise la plausibilité du texte, pas sa véracité. Dans le code, l'hallucination prend la forme d'une fonction inexistante, d'un paramètre inventé ou d'une règle de calcul erronée. Le risque n'est pas seulement technique. Une règle de gestion hallucinée dans un moteur de calcul de frais engage la conformité et la réputation de l'établissement.
La troisième est l’absence de mémoire persistante entre les sessions. Le modèle ne conserve ni les décisions architecturales prises précédemment ni les conventions qui en découlent, sauf si elles lui sont de nouveau fournies. Il peut ainsi produire, au fil des interactions, des choix localement pertinents mais contradictoires entre eux : variations de structure, de nommage, de dépendances ou de patterns techniques. Cette accumulation d’incohérences dégrade progressivement la maintenabilité et génère rapidement de la dette technique, précisément le passif que les DSI bancaires s’efforcent depuis vingt ans de réduire dans leurs systèmes legacy.
La quatrième est la dérive des modèles. Un fournisseur met à jour ses modèles en continu, et un comportement validé aujourd'hui peut changer demain sans préavis. Pour un établissement bancaire, cette dépendance à un comportement non garanti relève du risque fournisseur, au même titre que toute externalisation critique.
Ces quatre propriétés sont intrinsèques aux modèles. Aucun choix de fournisseur, aucune montée de version ne les fera disparaître :
La fiabilité d'une application IA ne viendra pas du modèle, elle viendra du cadre qu'on lui impose avant chaque génération de code.
C'est exactement l'objet du Spec-Driven Development, ou SDD.
Le Spec-Driven Development (SDD) s'est imposé en 2025-2026, porté par des outils comme GitHub Spec Kit et AWS Kiro. Son principe tient en une phrase : l'outil reste le même, le LLM, mais on change le niveau de contrainte imposé avant chaque génération. Cette contrainte est matérialisée par un document de référence qu'il faut définir d'emblée car tout le raisonnement en dépend. Le Spec-Kit est le référentiel qui encadre la génération de code. Il regroupe les spécifications fonctionnelles, les guardrails de sécurité, c'est-à-dire les règles bloquantes que le code généré ne peut pas enfreindre, et les patterns d'architecture imposés à l'IA. Ce référentiel est versionné, au sens où il est géré exactement comme du code source : chaque modification d'une spécification est datée, attribuée à son auteur, soumise à relecture avant d'entrer en vigueur, et l'historique complet reste consultable. On sait donc à tout moment quelle version des règles a encadré quelle génération de code, et l'on peut revenir à un état antérieur du référentiel si une évolution s'avère mauvaise.
C'est cette discipline qui fait la qualité du processus : la génération cesse d'être un dialogue improvisé pour devenir une opération reproductible, traçable de bout en bout et auditable, ce qu'aucun contrôle en fin de chaîne ne peut garantir a posteriori.
Ce référentiel se compose de deux couches :
Un socle technique, défini par l'architecte, le Tech Lead et l'équipe sécurité, qui couvre l'architecture logicielle, l'intégration au système d'information existant et les exigences de sécurité. Il n'évolue que sur décision formelle des instances techniques, typiquement le comité d'architecture avec l'aval de la sécurité, jamais au fil d'un projet.
Une couche fonctionnelle adaptable, propre à chaque domaine applicatif (chaque « IT Line », c'est-à-dire chaque ligne de produits informatiques rattachée à un métier), qui porte les règles de gestion, les contraintes réglementaires et les exigences de performance du cas d'usage.
Appliqué avec rigueur, le SDD délivre quatre bénéfices structurants : la prévisibilité du code généré, un contrôle qualité intégré en amont plutôt qu'audité en fin de cycle, la portabilité des spécifications d'un modèle à l'autre qui réduit la dépendance fournisseur, et la capitalisation d'un référentiel réutilisable. Pour un Chief Risk Officer, ce dernier point change la nature de la dépense :
L'effort de spécification cesse d'être un coût de projet pour devenir un actif amortissable
Reste une limite, et elle est de séquencement, non de principe. Il faut ici distinguer deux objets que les présentations du SDD confondent trop souvent. D’un côté, le socle technique qui doit être figé avant toute exploration, car l’architecture et la sécurité d’une banque ne dépendent pas du besoin fonctionnel d’un projet donné. De l’autre, la spécification fonctionnelle qui doit rester évolutive : elle décrit ce que le produit fait pour son utilisateur et se précise au contact du réel. La rédiger entièrement en amont reproduit les travers documentés du cycle en V : des semaines de cadrage pour un besoin encore flou, des spécifications désalignées du terrain, une rigidité qui étouffe la découverte. Le SDD est le bon cadre. Le moment où l’on fige le « quoi » fonctionnel détermine s’il accélère ou s’il bloque.
C'est précisément ce moment que le VISP vient régler. Il se pose sur le SDD comme une couche d'orchestration : en amont de la génération, il fait émerger la spécification fonctionnelle au contact des utilisateurs ; puis il la confie à la chaîne SDD pour l'industrialiser sous contrainte. Le socle technique, lui, reste figé dès le départ, comme le SDD l'exige. Le besoin fonctionnel, à l'inverse, n'est jamais deviné a priori : le VISP le laisse se former dans l'usage réel avant de le graver, au plus près du métier. D'où un ordre des opérations en trois phases :
La phase d'extraction mérite d'être précisée car elle est le cœur opérationnel du pipeline. Elle consolide les acquis de la phase d'exploration dans un « prompt maître », le document d'entrée de la chaîne SDD, qui doit couvrir six axes d'information :
Trois éléments ne sont jamais extraits du PoC : l'architecture logicielle, l'architecture technique et les guardrails de sécurité. Le prototype informe le « quoi », les experts cadrent le « comment », et le protocole interdit formellement de réutiliser l'architecture du prototype. Cette interdiction est la digue qui empêche le code jetable de l'exploration de contaminer l'application finale, et elle répond directement à l'exigence de séparation des environnements que tout auditeur bancaire connaît.
La règle de gouvernance centrale du VISP est simple : les phases 1 et 2 sont entièrement et exclusivement gérées par l'Augmented BA (ABA), une évolution du Business Analyst formée à la lecture de code, à l'ingénierie de prompts et aux fondamentaux de l'architecture. Les ingénieurs n'interviennent qu'en phase 3, lorsqu'ils reçoivent un Spec-Kit assaini et sécurisé.
Cette exclusivité n'est pas une commodité d'organigramme. Elle crée un pare-feu opérationnel aux effets mesurables. Côté métier, l'ABA absorbe les pivots, les hésitations et les découvertes de la phase exploratoire sans jamais mobiliser la capacité d'ingénierie, ce qui protège le plan de charge des équipes de développement contre la volatilité naturelle de l'exploration. Côté ingénierie, les développeurs ne reçoivent jamais un besoin flou. Ils reçoivent des spécifications ancrées dans un usage observé, purgées des cas limites non arbitrés, accompagnées de critères d'acceptation mesurables. Côté risque enfin, ce point de contrôle unique établit une traçabilité continue entre le besoin exprimé, le prototype validé et le code généré, exactement la chaîne de responsabilité que l'AI Act impose de documenter sur la gouvernance des modèles.
Ce rôle est le levier d'efficacité optimal du dispositif, et sa rareté constitue le premier risque d'exécution. Un binôme développeur et spécialiste métier peut remplir la même fonction, au prix d'une latence accrue puisque chaque décision exige un échange là où l'ABA arbitre seul. Toute DSI qui déploie le VISP sans plan de formation transforme un protocole de vitesse en goulot d'étranglement humain. L'upskilling de ce profil n'est pas un sujet RH périphérique. C'est la condition de matérialisation du gain de productivité.
Le choix entre les deux approches se résume à une question simple : sait-on déjà précisément ce que le produit doit faire ?
Si oui, le SDD classique est la bonne voie. C'est le cas des projets encadrés par une réglementation stricte, des migrations où les spécifications existent déjà, ou des évolutions sur un périmètre que les équipes maîtrisent. Dans ces contextes, fréquents en banque, une phase d'exploration n'apprendrait rien qu'on ne sache déjà. Elle ajouterait du délai sans apporter de valeur.
Si non, le VISP s'impose. Un nouveau service, un parcours client à inventer, un cas d'usage IA dont la valeur reste à démontrer : autant de situations où rédiger les spécifications avant d'avoir rien montré au métier revient à parier. Le SDD classique semble alors plus simple, puisqu'il n'y a qu'un seul processus à piloter. Mais cette simplicité est trompeuse. Le prix se paie plus tard, sous forme de spécifications à réécrire, de fonctionnalités développées à côté du besoin et d'allers-retours entre le métier et les développeurs. L'arbitrage tient en une ligne :
Le détour par l'exploration coûte quelques jours au départ et en économise des semaines à l'arrivée.
Dans les deux cas, le développeur conserve le dernier mot sur le code, dont la trajectoire reste guidée par le Spec-Kit. Et dans les deux cas, le socle technique est identique : le choix de l'approche ne change rien à la solidité de l'intégration au système d'information ni au niveau d'exigence de sécurité.
Trois actions constituent un point de départ réaliste :
Conclusion
Les établissements qui industrialiseront durablement l'IA générative ne seront pas ceux qui consomment le plus de tokens. Ce seront ceux qui sauront séparer deux natures de décision. D'un côté ce qui doit être fixé dès le départ, l'architecture et la sécurité, la structure porteuse sur laquelle tout repose. De l'autre ce qui doit rester malléable, façonné par l'usage aussi longtemps qu'il le faut. Fige-t-on le besoin trop tôt, on retrouve la rigidité du cycle en V ; trop tard, on accumule la dette qu'on prétendait fuir. Le VISP ne change rien à la technologie disponible, il fixe seulement l'instant du basculement, où l'on cesse d'explorer pour livrer, ce que ni le modèle ni la donnée ne trancheront jamais à la place d'un humain.
Souscrivez à notre liste pour bénéficier de perspectives sur votre marché.
