Spécial vibe coding

Pablo Nastar, en R&D à Toulouse depuis 2019 après plusieurs années dans la recherche, se lance avec une équipe de trois personnes (un designer, un jeune ingénieur et lui). Il s'occupe du volet business et donne des formations à l'IA, en particulier pour les architectes du BTP. Il a présenté, à partir d'un support généré avec NotebookLM, la méthode de développement que son équipe utilise en interne pour fiabiliser le code produit par l'IA.

D'où vient la méthode : un problème de management

• Déléguer sans dire comment. Souvent en déplacement, Pablo Nastar a confié le développement à un jeune ingénieur brillant mais peu expérimenté, qui travaille à distance. Les résultats le décevaient. Son constat : la faute lui revenait. Il n'avait ni fait d'onboarding ni formé la personne, et lui demandait de reproduire quinze ans d'expérience. Il donnait l'objectif, pas les étapes ni la manière de valider chaque pas.
• Comprendre avant de coder. Le réflexe du débutant est de coder tout de suite. Pour Pablo Nastar, qui dit privilégier l'efficacité et ne pas vouloir « aller au lit » avec une base de données mal configurée ou une faille de sécurité non maîtrisée, il faut d'abord comprendre ce que l'on fait.
• La chaîne de production de Ford, appliquée au code. L'idée : standardiser les process comme sur les lignes d'assemblage automobiles des années 1910. Pablo Nastar a rédigé, avec l'aide de l'IA, une procédure d'environ 300 pages qui décrit tout, « de A à Z » : ce qu'il veut, ce qu'il attend, comment le faire et les points de contrôle.

Les limites du vibe coding sans méthode

Selon Pablo Nastar, coder « à l'arrache » avec l'IA produit toujours les mêmes problèmes :

• Suppositions non approuvées : le modèle part sur des choix que personne n'a validés, par exemple une version de Python datant de 2015.
• Pollution du contexte : trop d'informations finissent par tromper le modèle, surtout quand plusieurs modèles travaillent sur le même code.
• Manque de traçabilité : sans plan ni constat écrit, impossible d'approuver ce qui a été fait.
• Problèmes de câblage : une interface est créée mais rien n'est connecté derrière, on clique sur un bouton et il ne se passe rien.
• Reproductibilité nulle : impossible d'obtenir deux fois la même qualité.

Première tentative : Spec-Kit

• Le principe. Spec-Kit, un repo open source disponible sur GitHub, accompagne la rédaction d'un PRD. On décrit dans un document tout ce que le projet doit faire, l'outil en tire des spécifications découpées par phase, puis un plan d'exécution en tâches. L'implémentation se fait ensuite phase par phase, dans l'ordre, et tâche par tâche.
• Les limites rencontrées. Contexte épuisé rapidement, spécifications parfois floues, écart avec les outils techniques de l'équipe, peu de possibilités de configuration. Pablo Nastar le décrit comme « une bouteille lancée à la mer » : utile, mais incomplet. L'équipe l'a donc adapté à son propre produit.

Le modèle de traçabilité atomique

Le principe : fragmenter les idées et le code en unités élémentaires, et développer sur chacune. L'objectif est de garder la gouvernance (décider soi-même du stack) et un point de contrôle humain : la machine n'exécute rien sans demander la permission. La « décomposition atomique » produit un très grand nombre de tâches isolées.

Mécanique 1 : les stations de connaissances

• 18 stations, toutes ne sont pas utilisées par le modèle : certaines contiennent de la connaissance théorique qui ne sert qu'à l'équipe.
• Une structure commune pour chaque station : objectifs, procédures, livrables, exigences et critères de « porte ». Chaque station a une porte à franchir avant de passer à la suivante.
• Un schéma d'erreur standardisé : chaque problème est décrit de la même manière. Quand le développeur à distance bloque, il envoie une capture et le récapitulatif, et Pablo Nastar peut diagnostiquer en un coup d'œil.
• Scoping et multi-tenant définis dès le départ : quel utilisateur a quels droits, et pourquoi. « C'est bête, mais c'est pas toujours évident. »
• Exigences d'idempotence et de pagination, posées d'emblée.
• Veille concurrentielle intégrée. Avant de construire, on vérifie avec le modèle que l'analyse de marché et la veille ont été faites. La machine télécharge les applications concurrentes, s'y crée des comptes, les teste, repère les points de blocage, lit les avis négatifs sur Google Maps, et ces retours alimentent les applications de l'équipe.

Mécanique 2 : les sous-agents

• 21 sous-agents « dorment » dans le repo en attendant l'appel de l'orchestrateur. Un autre repo de l'équipe en compte entre 60 et 70.
• L'orchestrateur est Claude, mais selon Pablo Nastar ce pourrait être un autre modèle, comme Gemini Pro.
• Des agents spécialisés : UX/UI, TypeScript, shadcn, back-end… Ils ont tous été créés par l'équipe.
• Un rôle appelé à diminuer. Selon Pablo Nastar, les sous-agents compensent surtout la taille limitée du contexte. Il l'estimait à 110 000 tokens, avec un compactage automatique au bout de quinze à vingt minutes « dont on ne sait pas ce qu'il garde », et attendait pour la semaine suivante une nouvelle version de Claude Code avec un million de tokens.
• Ralph Wiggum, en mode laboratoire. Pablo Nastar teste cette boucle qui relance l'agent en continu jusqu'à rencontrer un blocage, pour faire tourner le développement pendant la nuit. Elle ne fait pas tout seule, mais fait gagner du temps et bloque moins sur les permissions.

Mécanique 3 : le contrôle humain

• Revue du stack technique : à partir des requirements, la machine recommande des choix, et l'humain valide ou refuse chacun. « Moi, j'aime pas l'oignon, je le prends pas. »
• Checkpoint de validation des dépendances, avec beaucoup de versioning pour la sécurité.
• Spécifications UI : le point faible reconnu de l'équipe, « on n'a pas un très bon goût ». Pablo Nastar a salué la page montrée par un autre intervenant de la soirée.
• Une matrice de validation : un tableau où chaque décision est validée ou non par l'humain.

Comment la présentation elle-même a été faite

• Un récap, puis deux plans. Faute de temps, Pablo Nastar a demandé à son équipe un récapitulatif de tout le projet, raconté sous forme d'histoire et compréhensible par des non-développeurs. Plan A : le donner à NotebookLM pour générer le support.
• Plan B, la page web vibe codée. Captures d'écran du repo GitHub et prompt de spécifications envoyés à Google AI Studio et Stitch : une page de présentation prête en trente minutes, avec quelques bugs, un QR code, et les liens vers son profil LinkedIn et ses formations. Pablo Nastar y voit lui-même « l'hypocrisie » de sa position : il dit ne pas aimer le vibe coding, mais s'en sert quand le temps manque.