DU DÉVELOPPEMENT À LA PRODUCTION

L'IA peut concevoir un produit en un week-end. La production nécessite toutefois une prise en charge, des tests et une définition rigoureuse de ce qui constitue un produit « terminé ». Voici la répartition des rôles.

DU DÉVELOPPEMENT À LA PRODUCTION
Logiciel sur mesure et architecture guide 6 min de lecture révisé 25 juil. 2026

← Tous les guides Tous les guides de ce sujet

Sur cette page
  1. À quoi sert le « vibe coding » ?
  2. À quel stade cela pose-t-il problème en production ?
  3. Les garde-fous qui permettent sa mise en production
  4. Une boucle pratique que nous utilisons
  5. Quand il ne faut pas utiliser le « vibe code » pour le noyau
  6. En résumé
  7. En quoi cela diffère-t-il du travail sur Claude axé sur les spécifications ?

À quoi sert le « vibe coding » ?

Le « Vibe coding » consiste à guider un agent de programmation basé sur l'IA en s'appuyant davantage sur l'intention et le bon goût que sur un cahier des charges formel : Cursor, Claude Code, Copilot, Windsurf et autres outils similaires. Cette approche est idéale pour les prototypes rapides, les outils internes, les migrations avec un « avant » et un « après » clairement définis, la mise en place de l'interface utilisateur et le code de liaison fastidieux que l'on préfère éviter d'écrire.

C'est d'ailleurs ainsi que de nombreux fondateurs lancent désormais leurs produits. Il n'y a rien de mal à cela. L'erreur, c'est de considérer une démo locale encore à l'état brut comme un système de production. Les utilisateurs, les paiements, l'authentification, le SEO, l'accessibilité et la réalité des astreintes ne se soucient guère du fait que l'agent ait eu l'impression que le système était rapide.

Point clé : utilisez le « vibe coding » pour explorer et accélérer. Ne confondez pas la rapidité de création avec la capacité à répondre aux besoins des clients.

À quel stade cela pose-t-il problème en production ?

Voici les tendances que j'observe lorsque les applications développées par l'IA sont confrontées à un trafic réel :

Absence de propriété de l'architecture

L'agent se fera un plaisir de créer un troisième modèle pour la récupération des données, car l'instruction ne l'interdisait pas. Six semaines plus tard, personne ne sait quel modèle est le modèle de référence.

Authentification et paiements dans le scénario idéal

La connexion fonctionne sur le compte de démonstration. Les cas limites, l'expiration de la session, les tentatives de connexion via webhook et les vérifications d'autorisations ne sont que de la fiction tant qu'un être humain ne les a pas mis par écrit et testés.

Performances invisibles et dette SEO

Des coques générées côté client, des images hors limites et des métadonnées manquantes sont livrées parce que l'agent a été optimisé pour que « ça s'affiche correctement dans Chrome ».

Secret et l'expansion d'env

Des clés dans les exemples de fichiers « chat logs.env » qui sont réels, ainsi que des déploiements de prévisualisation qui communiquent avec les bases de données de production.

Point clé à retenir : les échecs de production après le codage par vibration relèvent généralement de la responsabilité de l'utilisateur et de cas particuliers, et non de la qualité du modèle.

Les garde-fous qui permettent sa mise en production

Glissière de sécuritéPourquoi est-ce important ?Seuil minimal
Définition écrite de « terminé »Fermeture de la salle de démonstrationListe des états d'authentification, de paiement, d'erreur et des états vides
Commencez par une fine tranche verticaleTémoigne de la voie risquéeUn parcours utilisateur réel en environnement de préproduction avec une structure de données réelle
Vérification manuelle des chemins critiquesLes agents ne bénéficient pas des primesAuthentification, facturation, migrations, routes SEO publiques
Contrôles automatisésDétecte les régressions réintroduites par les agentsVérification des types, analyse Lint, tests de fumée, CWV sur les modèles clés
ObservabilitéOn ne peut pas réparer ce qu'on ne voit pasSuivi des erreurs + analyses de base sur les produits avant le lancement
Plan de retour en arrièreUne génération rapide nécessite une annulation rapideMigrations réversibles, indicateurs de fonctionnalité pour les interfaces utilisateur à risque

Chez Seahawk, nous avons traité les agents comme des juniors agressifs avec une vitesse de frappe infinie. Ils rédigeaient. Les humains possédaient toujours l'architecture, la sécurité, et la décision de lancement. Pour le flux de travail plus long que j'utilise quand je construis avec Claude délibérément, voir le guide de flux de travail axé sur les spécifications Claude et le pilier de logiciels personnalisés.

Point clé : rédigez la liste des tâches terminées avant d'ouvrir l'agent. Passez vous-même en revue les chemins qui vous semblent risqués.

Une boucle pratique que nous utilisons

1. Décrivez le besoin de l’utilisateur en un paragraphe. 2. Dressez la liste des éléments non négociables (fournisseur d’authentification, CMS, hébergement, accessibilité, SEO). 3. Laissez l’agent mettre en place une structure de base à partir de cette liste. 4. Testez l’application dans les cas de figure défavorables le jour même. 5. Supprimez les abstractions sophistiquées inventées par le développeur et que vous n’avez pas demandées. 6. N’ajoutez des tests que là où une défaillance aurait un coût élevé. 7. Déployez une version très ciblée. 8. N’élargissez le périmètre qu’ensuite.

Si l'étape 4 échoue deux fois de suite, arrêtez de générer des prompts et rédigez un petit cahier des charges. Le « vibe coding » sans boucle de contrôle devient une production effrénée de prompts.

Point clé : Alternez entre création et utilisation critique. Si vous ne faites que suivre le mouvement, vous ne ferez que présenter des démonstrations.

Quand il ne faut pas utiliser le « vibe code » pour le noyau

Ne laissez pas l'agent improviser le grand livre comptable, le modèle d'autorisation ou les migrations de données d'un système qui compte déjà des clients. Ne concevez pas à l'aveuglette une refonte de l'architecture de l'information en production sans plan précis. Ne confiez pas la modélisation des menaces à une simple fenêtre de chat.

Implémentez en Vibe-Code les opérations CRUD de l'interface d'administration, le script qui renomme un dossier de ressources, la première version d'un tableau de bord interne, ainsi que la PR de migration une fois que quelqu'un aura défini la modification du schéma.

Point clé : évitez que les agents n'aient accès à des ressources financières irréversibles, à des autorisations ou à des structures de données jusqu'à ce qu'un humain ait défini les règles.

En résumé

Le « Vibe coding » est un outil de levier, et non une méthodologie de développement. Les équipes qui s'imposeront en 2026 utilisent quotidiennement des agents, mais leurs réunions « stand-up » restent tout de même assez ennuyeuses : définition de « terminé », examen des chemins critiques, performances sur le terrain et plan de repli.

Si vous avez besoin d'aide pour transformer un prototype développé à la vitesse de l'IA en un produit prêt à être proposé à vos clients, sachez que cela fait désormais partie des prestations habituelles d'une agence. Apportez le dépôt et la liste des tâches terminées. Laissez votre confiance en la démo à la porte.

Point clé : lancez la version que vous êtes en mesure de faire fonctionner, et non la démo qui vous a impressionné vendredi soir.

En quoi cela diffère-t-il du travail sur Claude axé sur les spécifications ?

Le travail basé sur un cahier des charges commence par un contrat écrit : entités, parcours, contrôles de réception ; ensuite, l'agent comble les lacunes. Le « vibe coding » part d'une intuition et d'une idée de départ, et ne se concrétise en un contrat que lorsque la réalité s'y oppose. Les deux approches sont valables. L'erreur consiste à recourir au « vibe coding » dans un contexte qui nécessitait déjà un contrat.

Règle générale : qu'il s'agisse d'un projet « greenfield » ou d'un outil interne, privilégiez d'abord l'intuition. Pour un produit multi-locataires, les paiements ou une surface SEO publique générant déjà du trafic, privilégiez d'abord le cahier des charges. Notre guide « Claude » sur les workflows axés sur le cahier des charges aborde en détail la deuxième approche. Ce guide présente la première approche, avec des freins liés à la production.

Point clé à retenir : explorez l'ambiance. Renforcez les spécifications. Ne négligez pas la passation de relais.

QUAND VOUS SOUHAITEZ ÉCHANGER