Cybercoding Codex history

Imaginez deux châteaux.

Le premier paraît magnifique de loin — des tourelles qui accrochent la lumière, des bannières qui flottent, un pont-levis qui s’abaisse sur commande. Mais approchez-vous, et vous remarquez que les fondations sont en sable. Les murs sont en contreplaqué peint. C’est un décor de cinéma, construit vite, construit pour être vu, jamais construit pour être habité.

Le second château est moins photogénique. D’épais murs de pierre, des douves, un donjon qui a survécu à des sièges. Il a fallu plus de temps pour le construire, et il ne cherche pas à vous impressionner de loin : il cherche à tenir encore debout dans cent ans.

Cette image — un château coupé en deux, fragile d’un côté, fortifié de l’autre — est celle par laquelle nous avons introduit la différence entre le vibecoding et le cybercoding sur scène à l’AI Summit Barcelona. C’est une image juste, et pas malveillante. Le vibecoding n’est pas une erreur en soi ; c’est un décor de cinéma, et les décors de cinéma ont leur utilité. L’erreur, c’est d’y installer sa famille.

Ce livre raconte comment nous l’avons appris à nos dépens, ce que nous avons bâti à la place, et comment vous pouvez utiliser la même approche — que vous soyez un développeur solo lançant votre premier SaaS, un CTO cherchant à reprendre le contrôle du code d’une scale-up, ou un RSSI face à une échéance de conformité NIS2 avec un portefeuille d’applications historiques que personne ne veut toucher.

Tout commence, comme souvent en pareil cas, par quelqu’un qui veille tard un week-end.

Thomas, l’un de nos développeurs, passe un week-end à s’amuser avec un nouvel outil appelé bolt.new — l’une des premières plateformes fonctionnant directement dans le navigateur, où l’on peut décrire une application en langage naturel et regarder l’IA générer du code fonctionnel sous ses yeux, en direct.

Ce n’est pas le premier outil de codage par IA que l’on ait vu. Mais c’est le premier qui donne l’impression d’une démo devenue réelle — pas d’installation locale, pas de code répétitif à écrire, juste une consigne et une application qui tourne quelques secondes plus tard. Dès le lundi, Thomas en a montré la moitié à l’équipe.

Ce week-end marque, autant qu’un moment précis puisse le faire, la naissance de ce que le secteur appellera plus tard le vibecoding : décrire ce que l’on veut en langage naturel et laisser un modèle d’IA écrire — et souvent déployer — le code, l’humain pilotant davantage au feeling qu’à la spécification.

C’est grisant. C’est aussi, nous l’apprendrons dans l’année qui suit, incomplet.

Nous ne déployons pas le codage par IA progressivement. Nous le déployons partout, délibérément, aussi vite que possible. Chaque outil interne, chaque prototype, chaque élément du backlog qu’on « comptait bien corriger un jour » devient un cas de test. La consigne donnée à l’équipe est simple : quoi que vous soyez sur le point de construire à la main, essayez d’abord avec l’IA.

Les résultats sont inégaux, et cette inégalité se révèle être la donnée la plus précieuse que nous ayons pu récolter. Les interfaces prennent forme en quelques heures. Tout ce qui touche à la logique métier, à la modélisation des données ou — très nettement — à la sécurité prend forme de façon bien plus incertaine, quand cela prend forme du tout.

Dès le printemps, une tendance s’impose : le codage assisté par IA est extraordinaire sur les parties du logiciel qu’un utilisateur peut voir, et peu fiable sur celles qu’il ne voit pas. Cet écart — un front-end brillant, un back-end fragile — allait définir l’année suivante de notre travail.

Nous obtenons notre premier test grandeur nature hors laboratoire : TopFlix Academy, une plateforme d’apprentissage en ligne. La version existante avait coûté bien plus d’1 million d’euros avec un développement traditionnel. Notre mission : la réécrire.

Deux personnes. Un été. Assisté par IA de bout en bout.

Ils livrent une plateforme fonctionnelle et déployée — pas une démo, un véritable produit gérant de vrais utilisateurs — pour une fraction du coût et du temps qu’une agence traditionnelle aurait nécessités. C’est le premier projet où la « réécriture assistée par IA » cesse d’être une expérimentation interne et commence à ressembler à une véritable alternative à la façon dont on construit un logiciel.

C’est aussi le projet qui nous convainc que cette approche a un vrai potentiel commercial — et la graine directe de ce qui deviendra plus tard la forge WakaStart.

Mais TopFlix Academy est une construction sur terrain vierge, avec un périmètre restreint et maîtrisé. Le véritable test — celui qui allait révéler les fissures du château — restait encore devant nous.

Claude Code et Opus 4.5 arrivent, et avec eux, un véritable saut qualitatif dans ce que le développement assisté par IA peut produire. Mais plus nos projets deviennent ambitieux, plus les limites du vibecoding pur se révèlent clairement.

Quelques schémas reviennent, projet après projet :

• Les front-ends brillent, les back-ends non. Les modèles d’IA excellent à produire des interfaces qui ont l’air justes. Ils sont bien moins fiables pour produire une logique back-end, des modèles de données et des intégrations qui tiennent la charge en usage réel.
• La conception de la base de données évolue au coup par coup. Sans schéma pensé dès le départ de façon délibérée, les tables s’ajoutent et se rafistolent au fil des consignes — la recette parfaite d’une dette structurelle invisible jusqu’au jour où elle ne l’est plus.
• Les back-ends prêts à l’emploi deviennent une béquille. Des outils comme Supabase rendent triviale l’ajout d’une authentification et d’une base de données. Ils comportent aussi de vraies limites en matière de montée en charge, de coût et — c’est essentiel — de sécurité, dès que l’on dépasse l’échelle du prototype.
• L’IA prend des décisions de sécurité que personne n’a validées. Livré à lui-même, un assistant de codage choisira une approche d’authentification, un modèle de permissions, une façon de gérer les secrets — et cela peut très bien convenir pour une démo. Cela résiste rarement à un audit de sécurité, et ce n’est presque jamais un choix délibérément fait par un humain. C’est précisément ce qui le rend exploitable — y compris, de plus en plus, par d’autres systèmes d’IA conçus pour repérer exactement ce type de décision non relue.

Rien de tout cela ne rend le vibecoding inutile. Pour les maquettes, les démos et le travail itératif sur le front-end, il reste réellement excellent — sans doute inégalé. Mais dès lors que l’on construit quelque chose destiné à faire tourner une entreprise, à héberger des données clients ou à survivre à un audit de sécurité, le château fragile cesse d’être charmant et devient un risque.

Il nous fallait une approche différente. Pas « l’IA écrit moins de code », mais « l’IA écrit du code à l’intérieur d’une structure qu’un humain a conçue en premier ».

De ce constat naît WakaStart : non pas un rejet du codage assisté par IA, mais son inversion délibérée. Là où le vibecoding part de l’interface et remonte vers l’intérieur, WakaStart part des fondations et avance vers l’extérieur — les décisions d’infrastructure et de sécurité sont prises en premier, délibérément, par des humains, et documentées de façon exhaustive, avant qu’une seule ligne de code applicatif ne soit écrite.

Deux disciplines sont au cœur de cette approche :

La rétro-ingénierie comme première étape. Pour tout système existant — historique ou non — la forge commence par tout extraire : comportement fonctionnel, structures de données, cas limites, particularités non documentées. Rien n’est supposé ; tout est vérifié par rapport au système réel.

Une spécification exhaustive avant la génération. Plutôt que de guider l’IA par consignes successives en espérant que l’architecture tienne, WakaStart produit un cahier des charges complet — parfois de plusieurs centaines de pages — qui décrit chaque écran, chaque règle, chaque exigence de sécurité, avant que la phase de codage ne commence. L’IA n’improvise pas l’architecture. Elle construit à partir d’un plan déjà validé par un humain.

C’est la graine de ce que nous appellerons bientôt le cybercoding : un développement natif à l’IA, mais avec la discipline de l’ingénierie logicielle traditionnelle — sécurité, architecture et infrastructure — appliquée avant que l’IA ne commence à écrire, et non ajoutée après coup.

La première vraie preuve de cette nouvelle approche est WakaSign, une plateforme de signature électronique conforme eIDAS — le genre de produit où « faites-nous confiance, c’est sécurisé » ne suffit pas ; la conformité doit être réelle, auditable, et intégrée dès le premier jour.

Construite en un seul mois, WakaSign est conçue pour concurrencer directement des acteurs établis comme Yousign et DocuSign, mais avec une sécurité dès la conception guidée par les exigences NIS2 dès le départ, plutôt que rajoutée a posteriori pour un audit de conformité.

C’est un petit produit avec une implication démesurée : si une entreprise peut passer de zéro à une plateforme de signature électronique conforme, prête pour la production, en trente jours — dans un domaine où la confiance est le produit — l’approche se généralise clairement au-delà d’une seule construction sur terrain vierge. La question n’était plus « est-ce que cela peut marcher une fois ? » mais « jusqu’où cela peut-il aller ? »

Ce n’est pas un compliment que nous nous sommes fait à nous-mêmes — c’est une paraphrase de ce que nous appelaient les premiers clients, début 2025, lorsque nous leur annoncions qu’une réécriture complète d’application prendrait un mois, et une certification ISO 27001, quatre semaines.

Le scepticisme était la réaction rationnelle. Personne ne tient de tels délais — ni avec le développement traditionnel, ni, franchement, avec le vibecoding, dès lors que la sécurité et la conformité entrent en jeu. Nous avons donc laissé les résultats parler pour nous.

Une série de projets a suivi, prouvant que ces délais n’étaient pas un coup de chance : Biped, Vicamed, OTeam, et d’autres, tous réécrits ou construits sur la forge WakaStart, tous livrés en semaines plutôt qu’en trimestres, tous portant la sécurité dès la conception dès le premier jour plutôt qu’en rustine.

Le temps que le scepticisme s’estompe, nous avions fait nos preuves — et un défi bien plus grand nous attendait.

Toute approche finit par rencontrer le projet qui la met véritablement à l’épreuve. Le nôtre fut le groupe Vinci.

Vinci exploitait un ensemble de systèmes ERP historiques développés sous Windev — un logiciel propriétaire utilisé pour gérer les filiales et sites distants du groupe. La situation qui les a contraints à agir était sans appel : l’éditeur de Windev avait été racheté par un groupe canadien, qui avait ensuite multiplié ses tarifs par environ 200. Rester sur la plateforme historique n’était plus une option viable.

Le hic : aucun code source n’était disponible. Seule la documentation subsistait. Une réécriture au sens traditionnel — lire le code, le comprendre, le réimplémenter — n’était pas envisageable. La seule voie possible consistait à reconstituer le comportement du système à partir de la seule documentation et de la connaissance métier.

Le périmètre : plus de 600 écrans et 200 formats de rapports imprimables, réécrits entièrement en une seule plateforme SaaS cybersécurisée et conforme NIS2, déployable instantanément sur tous les sites Vinci dans le monde.

Un mois plus tard, le projet est entré en phase de test et de pré-déploiement, avec une mise en production prévue avant la fin de l’année. C’est le projet par lequel nous avons ouvert notre conférence à l’AI Summit Barcelona — la preuve la plus claire que la forge, née d’une expérimentation d’un week-end avec bolt.new un an plus tôt, pouvait désormais s’attaquer de façon crédible à la modernisation d’applications historiques à l’échelle d’un grand groupe, sans code source de départ.

Mais Vinci est un engagement privé, s’étalant sur des mois. Pour le public de Barcelone, nous voulions quelque chose qu’il puisse voir se dérouler en temps réel, chronomètre en main, sans échappatoire possible. C’est le Wakathon.

Pour éprouver la forge sous une véritable pression du temps, et en public, nous avons organisé un Wakathon — un concours de développeurs où nos Waka Masters utilisent la forge WakaStart pour réécrire intégralement un logiciel existant, cette fois-ci contre la montre et en compétition directe les uns avec les autres.

La cible : Kanboard, une plateforme de gestion de projet open source bien connue, développée en PHP, sous licence MIT et donc libre d’être forkée, étudiée et réécrite sans restriction — une application de grande taille, comptant environ 150 écrans au total.

Les règles : trois Waka Masters ont reçu le briefing à 10 h le premier jour — l’application historique, son dépôt GitHub et sa documentation — et devaient livrer une version entièrement réécrite et cybersécurisée de l’application dès le lendemain.

• 10 h-12 h — rétro-ingénierie avec l’IA : essentiellement un échange de questions-réponses pour verrouiller l’architecture de sécurité définitive de la réécriture.
• 12 h-14 h (pause déjeuner) — génération des maquettes pour les 150 écrans de l’application existante, de sorte que chaque écran du système historique dispose d’un design cible correspondant avant même d’écrire une ligne de code.
• 14 h-17 h (environ, selon le Waka Master) — finalisation de l’étude de rétro-ingénierie, prise des décisions d’architecture pour la réécriture, et assemblage du cahier des charges à transmettre à la forge pour la nuit.
• Après 17 h — les trois cahiers des charges concurrents entrent dans la forge. Claude dispose d’une fenêtre nocturne de cinq heures pour coder chaque application dans son intégralité, sans supervision, à partir des seules spécifications.

Jour deux, 9 h — les Waka Masters reviennent découvrir ce que Claude a construit pendant la nuit. Deux d’entre eux trouvent une application quasiment prête pour la production dès le départ. Le troisième doit relancer une seconde passe : sa spécification fonctionnelle n’était pas assez précise, et il en résultait quelques écrans manquants — un rappel utile que la qualité de la spécification détermine la qualité du résultat.

Moins de deux heures plus tard, les trois Waka Masters disposent d’une réécriture complète et cybersécurisée de Kanboard — un peu avant midi le deuxième jour, soit environ 48 heures après la remise initiale du brief.

C’est cette application que nous avons présentée en direct sur scène à Barcelone : l’interface PHP d’origine, indéniablement datée, juxtaposée à sa version réécrite — les mêmes fonctionnalités, sécurisées dès la conception, construites presque entièrement par l’IA, à partir d’une spécification que trois humains ont mis une journée de travail à produire.

L’outil derrière tout cela est WakaNalytics — le moteur d’analyse et de spécification de la WakaForge. Voici, étape par étape, comment un projet la traverse concrètement.

1. Choisir le format final. Que doit livrer la forge au final : une application SaaS, une application iOS, une application Android, un exécutable de bureau pour Windows, macOS ou Linux — ou une combinaison de tout cela ?
2. Choisir le type de projet. Une toute nouvelle application construite à partir d’une spécification ; la reprise d’une base de code historique existante (notre exemple Kanboard) ; la réécriture d’une application à partir de la seule documentation fonctionnelle, typiquement le cas des systèmes historiques de type Windev (notre exemple Vinci) ; ou l’extension d’un projet WakaStart existant avec de nouvelles fonctionnalités. Ce choix compte plus qu’il n’y paraît — il détermine directement quelles consignes de rétro-ingénierie, d’analyse et de spécification seront sélectionnées ensuite, puisqu’elles dépendent à la fois du format cible et de la nature du projet.
3. Charger les sources. Les fichiers source et la documentation disponible sont chargés dans WakaNalytics.
4. Établir le contexte. Une première consigne définit le contexte global du projet — ce qu’il est, ce qu’il fait, à qui il s’adresse.
5. Analyser. Des consignes spécifiques calculent la complexité du projet, et en déduisent un budget et un calendrier approximatifs — tout en identifiant, ce qui est tout aussi important, les éléments de sécurité manquants dans la version d’origine, afin que ces lacunes soient traitées dès la conception plutôt que découvertes plus tard.
6. Spécifier et maquetter. WakaNalytics génère entre six et dix-huit spécifications techniques, ainsi que des maquettes pour chaque écran de l’application. Chaque écran — 100 % d’entre eux — est revu et validé par le porteur du projet avant de poursuivre.
7. Assembler le cahier des charges final. Ce n’est qu’une fois toutes les étapes précédentes achevées que la forge assemble le document à partir duquel Claude construira réellement — fondé sur tout ce qui a été généré et discuté lors de la phase d’analyse, et non improvisé à la volée.

Et Claude ne construit pas seul. En moyenne, 29 agents spécialisés sont déployés tout au long de la construction — couvrant le back-end, le front-end, le design, l’UX, la sécurité, ainsi que la gestion des identités et des accès — chacun veillant à ce que le résultat final reste aligné avec les exigences consignées dans le cahier des charges et avec l’infrastructure sécurisée sur laquelle il sera déployé.

Le déploiement, enfin, tient en un seul clic. L’automatisation CI/CD, le provisionnement des environnements de développement, de préproduction et de production — tout cela est déjà intégré dans la couche d’hébergement de WakaStart. Il n’y a plus rien à construire à ce niveau-là. C’est une pile complète et déjà intégrée — et non un back-end de type Supabase greffé après coup, un schéma que l’on retrouve typiquement dans le vibecoding pur.

À ce stade, le tableau devrait être suffisamment clair pour être énoncé simplement.

En pratique, cela signifie :

• L’infrastructure décidée avant le code. Hébergement, gestion des secrets, identités et accès — choisis délibérément, et non dictés par les besoins ponctuels du front-end. WakaStart, par exemple, fonctionne sur une infrastructure souveraine européenne, sur Kubernetes, avec Keycloak pour la gestion des identités.
• Alignement code-infrastructure. Les spécifications sont rédigées en tenant compte de l’infrastructure déjà choisie, de sorte que les deux ne divergent jamais.
• La sécurité dès la conception et le Zero Trust, appliqués à chaque étape — non pas comme un audit unique en fin de parcours, mais intégrés à chaque phase :
  1. Analyse — les droits, les profils utilisateurs, la sensibilité des données et les implications RGPD sont cartographiés avant toute chose.
  2. Spécification fonctionnelle exhaustive, avec des maquettes HTML pré-validées par rapport à un design system — Claude Code remplaçant ici, dans les faits, des outils de design traditionnels comme Figma.
  3. Conception de la base de données, réalisée une fois, de façon globale — et non rafistolée progressivement au fil des consignes.
  4. Un seul fichier de spécification exhaustif, souvent de plusieurs centaines de pages, remis à l’IA de codage — afin que le modèle construise à partir d’un plan, plutôt que d’inventer ses propres règles en cours de route.
  5. CI/CD sécurisé, avec analyse des dépendances et des CVE bloquant toute version contenant une vulnérabilité connue.
  6. Tests SAST/DAST systématiques et tests d’intrusion pilotés par IA, à chaque version, et pas uniquement au lancement.
  7. Hébergement sur une infrastructure conçue pour cela dès le départ — Kubernetes, Keycloak, un coffre-fort de secrets open source — une pile open source de niveau bancaire et militaire, et non une simple couche de commodité.

Le bénéfice d’aligner ainsi chacune de ces étapes de bout en bout — conception, développement, déploiement et hébergement — est que le système de management de la sécurité de l’information qui en résulte peut être certifié ISO 27001 sur l’ensemble du cycle de vie, une seule fois, plutôt que recertifié projet par projet. Chaque application construite ainsi hérite nativement de la conformité ISO 27001 et NIS2, au lieu de devoir la prouver à chaque fois depuis le début.

C’est toute l’idée. Pas « de l’IA, mais prudente ». Un point de départ entièrement différent.

Tout ce qui précède paraît abstrait tant qu’on ne le confronte pas à son propre point de départ. En pratique, nous en distinguons trois.

Des points de départ différents, des difficultés différentes. La même forge, la même vitesse, la même sécurité dès la conception, à chaque fois.

Nous avons ouvert ce livre avec deux châteaux — l’un bâti pour faire bonne impression de loin, l’autre bâti pour durer. Tout ce qui s’est joué entre les deux n’est finalement que le récit de la façon dont nous avons appris, projet après projet, lequel des deux nos clients avaient réellement besoin, et dont nous avons construit l’outillage pour le livrer à la vitesse que l’IA a rendue possible.

Si quelque chose ici vous parle — que vous lanciez un nouveau produit, que vous cherchiez à reprendre le contrôle des fondations d’une plateforme en croissance, ou que vous viviez avec des systèmes historiques que vous aimeriez moderniser sans mobiliser toute votre équipe — nous serions ravis d’échanger avec vous.

Pour remercier toutes les personnes présentes à l’AI Summit Barcelona 2026, et qui lisent ce livre à ce titre, nous proposons quatre offres, exclusives aux participants de l’AI Summit Barcelona et valables jusqu’au 30 septembre 2026 :

Scannez le code ci-dessous, ou rendez-vous directement sur wakastart.com et cybercoding.ai.

Merci de votre lecture. Maintenant, allez construire quelque chose qui tiendra encore debout dans cent ans.

— Denis Schirra
CEO, WakaStart / Wakastellar

Vibecoding

Décrire une application en langage naturel et laisser un modèle d’IA générer (et souvent déployer) le code, guidé par l’intuition plutôt que par une spécification formelle. Rapide et excellent pour les prototypes et les interfaces ; peu fiable pour la logique backend, l’architecture de données et la sécurité dès qu’un projet dépasse le stade du prototype.

CyberCoding

Un développement natif IA où les décisions d’infrastructure et de sécurité sont prises délibérément par des humains en amont, l’IA générant ensuite le code à l’intérieur de cette structure au lieu de l’inventer en chemin. Voir le chapitre 12 pour la méthodologie complète.

WakaForge / WakaNalytics

La plateforme de WakaStart pour rétro-concevoir, spécifier et générer des applications cybersécurisées. Voir le chapitre 11 pour un parcours pas à pas.

Wakathon

Un concours interne de développeurs utilisé pour éprouver la forge : réécrire une application existante depuis zéro, sous contrainte de temps, en public. Voir le chapitre 10.

NIS2

La directive européenne révisée sur la sécurité des réseaux et de l’information, qui relève les exigences de cybersécurité pour un large éventail d’entreprises opérant dans l’Union européenne ou la servant. De plus en plus un prérequis des contrats logiciels B2B à partir de 2026.

ISO 27001

La norme internationale des systèmes de management de la sécurité de l’information. Le SMSI de WakaStart est certifié sur l’ensemble du cycle conception-développement-déploiement-hébergement, ce qui étend la conformité native à chaque application construite sur la forge.

• TopFlix Academy — la première preuve d’une réécriture assistée par IA, été 2025 (chapitre 4).
• WakaSign — plateforme de signature électronique conforme eIDAS, construite en un mois (chapitre 7).
• Kanboard — la plateforme open source de gestion de projet réécrite pendant le Wakathon (chapitre 10).

En savoir plus, obtenir les outils ou activer votre offre AI Summit Barcelona (valable jusqu’au 30 septembre 2026) : wakastart.com · cybercoding.ai