DU CODE EXPLORATOIRE À LA PRODUCTION

Le code exploratoire consiste à piloter un agent de codage IA avec l'intention et le goût plutôt qu'avec une spécification formelle : Cursor, Claude Code, Copilot, Windsurf, et autres. C'est excellent pour les spikes, les outils internes, les migrations avec un avant et après clairs, l'échafaudage d'interface, et le code de plomberie ennuyeux que vous préférez ne pas taper.

C'est aussi comment beaucoup de fondateurs démarrent maintenant leurs produits. C'est normal. Le mode de défaillance est de traiter une démo verte en local comme un système de production. Les utilisateurs, les paiements, l'authentification, le SEO, l'accessibilité, et la réalité de l'astreinte ne se soucient pas que l'agent ait semblé rapide.

Point clé : utilisez le code exploratoire pour explorer et accélérer. Ne confondez pas la vélocité de génération avec la disponibilité à servir les clients.

Les schémas que j'observe quand les applis construites par IA rencontrent le trafic réel :

Pas de propriété de l'architecture

L'agent créera joyeusement un troisième schéma pour la récupération de données parce que le prompt ne l'a pas interdit. Six semaines plus tard, personne ne sait quel schéma est canonique.

Auth et paiements sur le chemin heureux

La connexion fonctionne sur le compte démo. Les cas limites, l'expiration de session, les tentatives de webhook et les vérifications de permission sont de la fiction jusqu'à ce qu'un humain les couche sur le papier et les teste.

Dettes invisibles en performance et SEO

Les shells rendus côté client, les images sans limite et les métadonnées manquantes se retrouvent en production parce que l'agent a optimisé pour « c'est bon dans Chrome ».

Prolifération de secrets et de variables d'env

Les clés dans les logs de chat, les exemples .env qui sont vrais, et les déploiements de preview qui parlent aux bases de production.

Point clé : Les pannes en production après du code fait à la vibe viennent généralement de la propriété et des cas limites, pas du QI du modèle.

Chez Seahawk, on traite les agents comme des juniors agressifs avec une vitesse de frappe infinie. Ils font des brouillons. Les humains gardent la main sur l'architecture, la sécurité et la décision de mise en production. Pour le workflow plus long qu'on utilise quand on construit volontairement avec Claude, voir le guide du workflow piloté par spécification Claude et le pilier logiciel personnalisé.

À retenir : Écrivez la liste des tâches terminées avant d'ouvrir l'agent. Testez vous-même les chemins critiques.

1. Énoncez le besoin utilisateur en un paragraphe. 2. Listez les points non-négociables (fournisseur d'auth, CMS, hébergement, accessibilité, SEO). 3. Laissez l'agent construire le scaffold en fonction de cette liste. 4. Testez l'appli sur les chemins problématiques le même jour. 5. Supprimez les abstractions astucieuses que l'agent a inventées sans qu'on les demande. 6. Ajoutez des tests seulement là où la casse est coûteuse. 7. Livrez une slice étroite. 8. Seulement après, élargissez le scope.

Si l'étape 4 échoue deux fois de suite, arrêtez de faire des prompts et écrivez une courte spécification. Le vibe coding sans une boucle qui se resserre devient du prompt churn.

À retenir : Alternez la génération avec l'utilisation adversariale. Si vous allez toujours de l'avant en vibes, vous ne faites que des démos.

Ne laissez pas l'agent improviser le registre de facturation, le modèle de permissions ou les migrations de données pour un système qui a déjà des clients. Ne faites pas du vibe coding d'une refonte de l'architecture informationnelle de production sans une carte. N'externalisez pas la modélisation des menaces à une fenêtre de chat.

Faites du vibe code pour l'écran d'admin CRUD, le script qui renomme un dossier d'assets, la première version d'un dashboard interne, et le PR de migration une fois qu'un humain a spécifié le changement de schéma.

Point clé : Tenez les agents éloignés de l'argent irréversible, des permissions et de la structure des données jusqu'à ce qu'un humain ait établi les règles.

Le codage par intuition est un outil de levier, pas une méthodologie de livraison. Les équipes qui gagnent en 2026 utilisent les agents quotidiennement et sonnent toujours ennuyeuses en standup : définition de « fait », examen sur les chemins critiques, performance sur le terrain, et un plan de rollback.

Si vous cherchez de l'aide pour transformer un prototype à la vitesse de l'IA en quelque chose sur lequel vous pouvez mettre des clients, c'est du travail d'agence normal maintenant. Apportez le repo et la liste de ce qui est fait. Laissez la confiance en démo à la porte.

Point clé : Livrez la tranche que vous pouvez exploiter, pas la démo qui vous a impressionné vendredi soir.

Le travail piloté par les spécifications commence par un contrat écrit : entités, routes, vérifications d'acceptation, puis l'agent comble les lacunes. Le codage par intuition commence par le goût et une invite et se resserre en un contrat seulement quand la réalité repousse. Les deux sont valides. L'erreur est d'utiliser le codage par intuition sur une surface qui avait déjà besoin d'un contrat.

Règle empirique : greenfield spike ou outil interne, intuition d'abord. Produit multi-locataires, paiements, ou une surface SEO publique avec du trafic existant, spécifications d'abord. Notre guide de flux de travail Claude piloté par les spécifications couvre le deuxième chemin en détail. Ce guide est le premier chemin avec des freins de production.

Point clé : Intuition pour découvrir. Spécifications pour durcir. Ne sautez pas la transition.