Chez OpenAI, les chefs de produit ne font plus de maquettes. Katia Gil Guzman, de l'équipe Developer Experience, le raconte dans un épisode enregistré en septembre 2026 : « tous les product managers codent avec Codex. Et au lieu de faire des prototypes et des Figma mock-up, ils vont directement l'implémenter dans le produit ». Elle décrit une pull request reçue d'un chef de produit qui n'a jamais été ingénieur logiciel de sa vie, et commente : « c'est parfait, en fait. Parfois, il y a quelques commentaires, mais sinon, je n'ai rien besoin de faire ».
Elle donne aussi la raison, et c'est la phrase qui compte : « pourquoi est-ce qu'on faisait tout ça ? Parce que ça coûtait cher de construire. Donc, en fait, on voulait être sûr de ne pas se tromper. » La maquette n'était pas une étape de méthode, c'était une assurance contre le prix du code. L'assurance devient inutile quand le sinistre ne coûte plus rien.
On peut écarter l'exemple d'un revers de main - OpenAI teste ses propres modèles, sans plafond de tokens, et l'intervenante le reconnaît elle-même quand son hôte le lui fait remarquer. Sauf que le même mouvement se constate dans une entreprise qui n'a rien d'un laboratoire d'IA.
4 000 créateurs et 500 applications en production, chez un opérateur ferroviaire
Deutsche Bahn donne à chacun de ses salariés une licence Power Platform. Le résultat, décrit dans une étude de cas publiée par Microsoft : une communauté de 4 000 citizen developers et plus de 500 applications en production. Deux exemples y sont chiffrés. Une application de rapport de service pour les équipes de nettoyage des trains fait tomber les erreurs dues à l'écriture manuscrite de 20 % à 2 % et fait gagner environ 70 minutes par service à ses responsables - soit, sur trois services par jour, 24 heures par semaine. Une application de maintenance des voies a enregistré 8 440 relevés en économisant trois minutes chacun : « ça fait 56 jours qu'on a rendus à l'équipe », dit son auteur.
Disons tout de suite le conflit d'intérêt : cette étude de cas est publiée par Microsoft, qui vend Power Platform. Les chiffres viennent des équipes de Deutsche Bahn, mais la page est un document commercial et se lit comme tel. Ce qui nous intéresse n'est d'ailleurs pas la performance annoncée, c'est le dispositif de gouvernance décrit autour - et il est, lui, détaillé avec une précision inhabituelle.
Ce que ça coûte quand personne ne regarde
Avant le dispositif, le risque. L'OWASP a publié une typologie des risques propres au développement par des non-informaticiens, et sa fiche sur les fuites de données est instructive parce que deux de ses cinq scénarios impliquent explicitement un assistant IA.
Dans l'un, un chef de produit demande à un assistant un script qui résume les tickets de support ; il colle dans l'invite des journaux bruts contenant des identifiants de comptes clients, et le code produit poste les résumés dans un canal interne ouvert à plus de deux cents personnes. Dans un autre, un créateur fait écrire un récepteur de webhook : l'assistant, « outil fonctionnel mais sans intention », journalise toutes les données entrantes sans les assainir, et un secret client finit lisible dans les journaux.
La fiche pointe aussi un risque qui n'est pas de sécurité mais d'exploitation : quand des non-techniciens relient des systèmes entre eux, ils créent des dépendances non documentées, rarement cartographiées, où un petit changement en amont se propage en cascade. C'est le genre de panne qu'on ne voit pas venir parce que personne n'a la carte.
À ce risque s'ajoute celui du code lui-même, et il est désormais mesuré. Une étude de Singapore Management University et de l'université Huazhong a analysé 302 600 commits attribués à cinq assistants de code dans 6 299 dépôts GitHub, en comparant l'analyse statique avant et après chaque changement. Résultat : 484 366 problèmes distincts, dont 89,3 % de code smells ; plus de 15 % des commits de chacun des cinq assistants introduisent au moins un problème ; et surtout 22,7 % des problèmes introduits sont toujours là à la dernière version du dépôt.
Ce dernier chiffre est le seul qui compte vraiment. Il ne dit pas que les agents écrivent du mauvais code, il dit que ce qu'ils introduisent ne se résorbe pas tout seul. À lire avec sa limite, que les auteurs posent eux-mêmes : l'étude ne retient que les commits dont l'origine est explicitement inscrite dans les métadonnées Git, et mesure la dette au travers de l'analyse statique - pas la dette d'architecture, ni celle de documentation, ni la couverture de tests.
C'est le même déplacement que celui que nous décrivions à propos des 2,3 milliards de tokens de Luc Bonnin : le travail ne disparaît pas, il part vers l'aval. La différence, ici, c'est que l'aval appartient à quelqu'un qui n'a pas écrit le code et ne sait pas qu'il en a hérité.
Le dispositif qui tient : deux niveaux, trois environnements, un approbateur
Revenons à Deutsche Bahn, parce que la gouvernance décrite est concrète et qu'elle répond point par point aux risques ci-dessus.
- Un centre d'excellence à deux niveaux. Un centre central définit les règles et standardise les composants communs ; des centres locaux portent la mise en œuvre au niveau de chaque filiale, avec son directeur informatique. Le responsable du sujet le formule sans détour : « je n'ai pas à traiter chaque question de chaque citizen developer, seulement celles que les experts locaux ne peuvent pas résoudre ». La gouvernance tient parce qu'elle se délègue.
- Trois environnements, et une porte entre eux. Les créateurs expérimentent en développement-test, passent en préproduction pour évaluation, et ne déploient qu'après. Ce qui est évalué est énuméré : criticité métier et valeur, gestion du risque, protection des données, sécurité.
- Un approbateur nommé. Ce sont les équipes d'experts locales qui accompagnent les créateurs, évaluent les applications et les approuvent quand elles sont prêtes. Personne ne met en production tout seul.
- De la formation, en volume. Plus de 2 000 sessions ouvertes une année ont été complètes en sept heures, et la communauté compte 11 000 personnes autour des ateliers et démonstrations.
Ce modèle ne supprime pas les risques de l'OWASP : il leur oppose un endroit où quelqu'un regarde. C'est la différence entre « les équipes métier produisent du logiciel » et « les équipes métier produisent du logiciel qui part en production ». Les deux phrases ne décrivent pas du tout le même niveau d'engagement.
Ce que le cadre ne règle pas : l'outil amplifie ce qui est déjà là
Reste une chose qu'aucun processus d'approbation n'attrape, et c'est l'apport du dernier document de ce lot. Prasanth Padharthi, directeur technique de HONO AI, a passé deux ans à faire traverser le vibe coding à une organisation d'une quarantaine d'ingénieurs. Sa conclusion tient en une phrase : l'outil ne change pas qui est un ingénieur, il amplifie ce qu'il apportait déjà.
Son exemple est parlant. Deux ingénieurs, même brief : un module d'import de fichier CSV, avec gabarit à télécharger, validation, succès et échecs affichés sur le même écran. Le premier livre exactement ça, proprement, accepté en revue du premier coup. Le second livre la même chose, puis continue : traitement en arrière-plan pour que l'utilisateur n'attende pas, journal d'audit nommant qui a importé quoi et quand, chaque ligne du fichier marquée réussie ou en échec avec son motif, et reprise possible à la ligne fautive plutôt qu'au début. Mêmes outils, même budget de temps. « Ni l'un ni l'autre n'a tort », écrit-il : le premier a construit ce qu'on lui a demandé, le second ce que l'utilisateur aurait fini par demander.
Il nomme aussi le coût caché, et ce n'est pas la facture de tokens : c'est « l'ingénieur qui a passé dix heures à rustiner des symptômes parce que le vrai problème était une question d'architecture qu'il n'a jamais pris le temps d'écrire ». Son exemple - une journée entière de correctifs sur un rendu PDF côté navigateur, quand la solution était de déplacer le rendu côté serveur en cinq minutes - se reconnaît de l'extérieur et jamais de l'intérieur, parce que « le modèle ne vous dit jamais de vous arrêter ».
D'où son protocole, qui tient en une ligne et mérite d'être volé : quand une session dépasse quatre-vingt-dix minutes sans direction claire, on ferme l'éditeur, on écrit l'énoncé du problème en français, et seulement ensuite on rouvre une session. Nuance d'honnêteté : il décrit son propre terrain, une organisation, sans mesure externe - à lire comme un retour d'expérience, pas comme une étude.
Trois questions avant d'ouvrir les vannes
Mises bout à bout, ces quatre sources donnent une position assez nette. Ouvrir la production de logiciel aux équipes métier fonctionne - c'est démontré chez un opérateur ferroviaire comme chez un laboratoire d'IA. Mais ce qui décide du résultat n'est pas l'outil, c'est trois réponses :
- Qui approuve, et sur quels critères écrits ? Chez Deutsche Bahn, les critères sont énumérés et l'approbateur est une équipe locale identifiée. Sans ça, la mise en production est un acte individuel sans contrepartie.
- Où va la dette, et qui la voit ? 22,7 % des problèmes introduits survivent. Si rien ne rattache une application à un responsable et à un historique, cette dette n'a simplement pas de propriétaire.
- Qu'est-ce qui empêche une donnée sensible de sortir ? La liste de prévention de l'OWASP est ennuyeuse et efficace : connecteurs limités à une liste approuvée, création de connecteurs sur mesure réservée, surveillance des flux qui sortent du périmètre, équipes sécurité associées aux revues des applications qui touchent des données sensibles.
C'est le terrain sur lequel Survol travaille, et autant le dire franchement plutôt que de le laisser deviner. Une version porte son origine - agent, humaine ou mixte - parce que l'unité de vérité est la version, pas l'auteur ; les contraintes techniques de l'organisation sont injectées au début de chaque session plutôt que recollées à la main dans chaque invite ; et une promotion vers la production passe par des vérifications déclarées. Ça ne remplace ni un centre d'excellence ni une équipe sécurité : ça donne l'endroit où leurs décisions s'inscrivent.
Nous avions déjà raconté les 280 pull requests de non-développeurs chez Alan. La différence avec ce qui précède tient en une ligne, et elle est de taille : chez Alan, les non-développeurs entraient dans le dépôt des ingénieurs, avec leur outillage, leur CI et leur revue. Chez Deutsche Bahn, 4 000 personnes construisent à côté du système d'information, sur une plateforme qui ne porte pas ces garde-fous par défaut. C'est le même mouvement, mais ce n'est pas du tout le même risque - et c'est pour le second qu'il faut inventer le cadre.
Sources
- Katia Gil Guzman (OpenAI, Developer Experience), « Pourquoi les product managers d'OpenAI ont arrêté les maquettes », podcast Just a Click, épisode enregistré en septembre 2026. Les citations sur les maquettes et le coût de construction en proviennent.
- Microsoft Learn, « Deutsche Bahn empowers citizen developers with Power Platform ». Étude de cas publiée par l'éditeur de la plateforme : les chiffres cités (4 000 créateurs, 500 applications, 20 % → 2 % d'erreurs, 8 440 relevés, 56 jours) et le modèle de gouvernance en proviennent.
- OWASP, « CD-SEC-04: Sensitive Data Leakage and Handling Failures », Citizen Development Top 10 Security Risks. Les scénarios de risque et la liste de prévention en proviennent.
- Yue Liu, Ratnadira Widyasari, Yanjie Zhao, Ivana Clairine Irsan, Junkai Chen, David Lo, « Debt Behind the AI Boom: A Large-Scale Empirical Study of AI-Generated Code in the Wild », Singapore Management University et Huazhong University of Science and Technology. 302 600 commits vérifiés, 6 299 dépôts, cinq assistants de code.
- Prasanth Padharthi, « The bimodal developer - vibe coding and the team you didn't know you had », juin 2026. Retour d'expérience du directeur technique de HONO AI sur une organisation d'une quarantaine d'ingénieurs.
- Les quatre sources ci-dessus autres que le podcast sont en anglais : les passages cités entre guillemets sont traduits par nos soins.
