Tutoriel de vibe coding avec Kimi : créer un produit sans écrire de code est plus facile, mais le mettre en production ne l’est pas

Kimi a transformé un workflow autrefois technique en un workflow conversationnel, mais ce changement crée un nouveau conflit entre construire rapidement et mettre en production de manière responsable. Ce tutoriel de vibe coding avec Kimi examine ce conflit à travers le parcours complet d’un produit, d’une spécification initiale à un déploiement public.

Le changement important n’est pas qu’un modèle d’IA puisse générer une page de destination. Les agents de codage peuvent désormais inspecter les fichiers d’un projet, modifier plusieurs composants, exécuter des commandes, lancer des tests et ajuster leurs plans après des échecs. Kimi Code, Qwen Code et les services de codage basés sur GLM placent ce workflow dans des terminaux et des environnements de développement.

Cela place les personnes qui créent pour la première fois dans une position inhabituelle. Elles peuvent produire davantage de logiciels avant de comprendre les systèmes qui les sous-tendent. Pourtant, l’hébergement, l’authentification, les bases de données, la sécurité, la configuration des domaines et les obligations réglementaires restent des problèmes d’ingénierie.

Andrej Karpathy a donné à cette pratique un nom mémorable en février 2025. Sa description mettait l’accent sur l’acceptation des modifications générées et l’oubli temporaire de l’existence du code. Cette attitude fonctionnait pour des projets expérimentaux de week-end, mais un produit public impose une norme différente.

La question utile n’est plus de savoir si une personne sans expérience en programmation peut créer une application. Elle le peut. La question plus difficile est de savoir si elle peut comprendre, tester, exploiter et rétablir l’application après qu’un agent l’a créée.

Les agents de codage Kimi gèrent désormais plus que la génération de code

Le passage d’assistant de chat à agent de codage change qui peut lancer un projet logiciel, mais il ne retire pas la responsabilité au créateur.

Un modèle de chat renvoie généralement du texte ou des exemples de code isolés. Un agent de codage peut travailler dans un projet, inspecter sa structure, modifier des fichiers, exécuter des commandes et observer le résultat produit. Cette boucle de rétroaction permet au système de poursuivre après la première réponse.

La distinction compte pour un créateur non technique. Copier du code entre un navigateur et un éditeur exige de savoir où chaque fragment doit être placé. Un agent peut localiser les fichiers pertinents et coordonner les modifications entre l’interface, le serveur, la base de données et la configuration.

Kimi décrit son client en ligne de commande comme un agent capable de lire et modifier du code, rechercher des fichiers, exécuter des commandes shell et réviser son plan à partir des retours. Son guide actuel de Kimi Code explique également comment le client peut générer un fichier AGENTS.md après avoir analysé un projet.

Ce fichier agit comme un contexte opérationnel pour l’agent. Il peut consigner la structure du projet, les commandes de build, les conventions et d’autres instructions qui doivent persister entre les tâches. L’agent obtient une carte au lieu de traiter chaque prompt comme une demande isolée.

Qwen Code suit un modèle similaire. Sa présentation de l’agent décrit un outil de terminal qui transforme les instructions produit en code et prend en charge une utilisation scriptée, non interactive. Il peut aussi se connecter via plusieurs options d’authentification et de fournisseurs de modèles.

Ces produits représentent un changement plus large dans l’interface du développement logiciel. L’utilisateur décrit le comportement, les contraintes et les critères d’acceptation. L’agent traduit cette intention en fichiers, commandes et tests.

Toutefois, le langage naturel n’est pas une spécification complète. Une demande telle que « créer un portail client » laisse sans réponse des questions cruciales. Elle ne dit rien sur la récupération de compte, les autorisations d’accès, la conservation des données, les paiements échoués, les journaux d’audit ou la prévention des abus.

Un ingénieur expérimenté remarque ces lacunes parce qu’elles ressemblent à des échecs antérieurs. Un débutant voit souvent l’interface visible et suppose que le système est presque terminé. Les agents de codage réduisent le temps d’implémentation, mais ils peuvent aussi masquer des décisions inachevées derrière un écran soigné.

Le guide chinois provenant d’AIHOT saisit bien ce nouveau workflow. Il présente des modèles nationaux, dont Kimi, GLM et Qwen, comme des voies accessibles pour passer d’une idée à un produit en ligne. Son conseil le plus pertinent apparaît vers la fin : un créateur peut éviter d’écrire du code, mais ne peut pas éviter de comprendre l’architecture.

Cette distinction devrait définir tout tutoriel sérieux de vibe coding avec Kimi. L’agent peut exécuter des tâches, tandis que l’humain reste responsable de définir le système et de juger s’il fonctionne.

Une spécification produit doit précéder le premier prompt

Une idée vague produit une démo convaincante, tandis qu’une spécification délimitée donne à l’agent une chance de produire un produit exploitable.

Le premier livrable ne devrait pas être du code. Il devrait s’agir d’une courte spécification produit couvrant les utilisateurs, les tâches, les données, les autorisations, les états d’échec et les critères de réussite. Ce document devient la référence lorsque l’agent commence à faire des suppositions.

Commencez par un utilisateur et une tâche. « Les freelances doivent transformer les notes de réunion en suivis client » est plus exploitable que « créer une plateforme de productivité IA ». L’énoncé plus étroit identifie une entrée, une transformation et une sortie.

Ensuite, définissez le plus petit parcours complet. Un utilisateur crée un compte, importe une note, examine un suivi généré, le modifie et exporte le résultat. Chaque étape devrait inclure ce que voit l’utilisateur et ce qui se passe lorsque l’action échoue.

Les données méritent leur propre section. Énumérez chaque type d’information que l’application stocke, sa provenance, qui peut la lire et quand elle doit être supprimée. Les documents sensibles exigent des protections différentes des données de catalogue publiques.

Les autorisations nécessitent aussi un langage explicite. Un administrateur, un utilisateur régulier et un visiteur anonyme ne devraient pas disposer des mêmes capacités. Si le produit prend en charge les équipes, précisez si les membres peuvent consulter les dossiers les uns des autres et qui peut retirer les accès.

Définissez ensuite le système comme plusieurs composants :

• L’interface affiche les écrans, les formulaires, la navigation et les retours.

• Le service applicatif applique les règles métier et coordonne les requêtes.

• La base de données stocke les utilisateurs, les dossiers, les autorisations et l’état.

• L’authentification vérifie l’identité et contrôle les sessions.

• Les services externes fournissent l’e-mail, les paiements, l’inférence IA ou le stockage de fichiers.

• L’hébergement rend l’application disponible et fournit les journaux, le réseau et les sauvegardes.

Un débutant n’a pas besoin de connaître chaque détail d’implémentation avant de commencer. Il doit reconnaître ces composants et demander où réside chaque responsabilité. Sinon, l’agent peut combiner silencieusement des préoccupations sans rapport dans un code fragile.

Le mode plan est utile à ce stade. Au lieu de demander à l’agent de construire immédiatement, demandez-lui d’inspecter la spécification, d’identifier les décisions manquantes, de proposer une architecture et de diviser le travail en jalons.

Le plan de l’agent devrait nommer les principales entités de données, routes, dépendances et la stratégie de test. Il devrait également énoncer les hypothèses. Les hypothèses cachées deviennent coûteuses une fois que plusieurs fonctionnalités en dépendent.

Demandez à l’agent de décrire l’architecture sans code. Si l’explication reste confuse, le produit n’est pas prêt pour une implémentation autonome. Retravaillez le plan jusqu’à ce que vous puissiez expliquer le flux de requêtes en langage clair.

Les prompts utiles définissent des preuves, pas de l’enthousiasme. « Ajouter une connexion » est incomplet. « Ajouter une connexion par e-mail, rejeter les sessions expirées, empêcher les utilisateurs d’accéder aux dossiers d’un autre compte, et écrire des tests pour ces cas » crée des exigences observables.

La même discipline s’applique au travail d’interface. Décrivez les états vides, les états de chargement, les erreurs de validation, les petits écrans, la navigation au clavier et les actions destructrices. Un tableau de bord généré qui ne gère que des données idéales reste une maquette.

Les créateurs peuvent conserver les exigences, les notes sources, les décisions de modèle et les observations de test dans un workflow d’IA consultable AI workflow. Ce contexte devient précieux lorsqu'un agent demande pourquoi un choix architectural antérieur a été fait.

Une spécification changera pendant le développement. C'est normal. La règle importante est de mettre à jour le document source avant de demander à l'agent de mettre en œuvre la nouvelle orientation.

Le tutoriel Kimi Vibe Coding : du plan à une version fonctionnelle

Le workflow agentique le plus sûr utilise de petites étapes vérifiables plutôt qu'une seule invite demandant une application entière.

Créez le projet dans un dépôt sous contrôle de version avant de commencer une mise en œuvre majeure. Le contrôle de version enregistre les modifications sous forme de commits, permettant à un développeur de comparer les révisions et de restaurer un état antérieur. Le commit initial doit contenir la spécification et une structure de projet minimale.

Demandez à l'agent de proposer une pile technologique fondée sur la simplicité opérationnelle. La réponse doit expliquer pourquoi chaque composant existe, comment il sera déployé et quelles alternatives ont été écartées. Évitez de choisir un framework simplement parce que le modèle l'a généré en premier.

La première étape doit établir la structure de l'application. Elle comprend la commande de développement, la configuration de l'environnement, la navigation de base, une vérification de l'état de santé et une commande de test. Aucune fonctionnalité métier ne doit avancer tant qu'un autre environnement propre ne peut pas exécuter cette structure.

La deuxième étape doit mettre en œuvre le modèle de données central. Demandez à l'agent de présenter les entités, leurs relations et les règles de propriété avant de générer les migrations. Une migration est une modification contrôlée de la base de données qui peut être appliquée de manière cohérente dans tous les environnements.

Examinez le schéma en langage clair. Quel enregistrement appartient à quel utilisateur ? Que se passe-t-il lorsqu'un compte est supprimé ? Deux enregistrements peuvent-ils accidentellement faire référence à des données absentes ? Les réponses révèlent si le modèle sous-jacent correspond au produit.

La troisième étape ajoute l'authentification et l'autorisation. L'authentification répond à la question de savoir qui est l'utilisateur. L'autorisation répond à la question de savoir ce que cet utilisateur peut faire. De nombreuses applications générées mettent en œuvre la première tout en traitant la seconde comme une préoccupation d'interface.

L'autorisation doit être appliquée par le serveur pour chaque opération protégée. Masquer un bouton n'est pas un contrôle d'accès. Un utilisateur malveillant ou curieux peut envoyer des requêtes sans utiliser l'interface prévue.

La quatrième étape met en œuvre un parcours produit complet. Résistez à l'ajout de pages de paramètres, de tableaux d'analyse ou de raffinements visuels avant que le parcours principal ne fonctionne. Une tranche verticale étroite révèle plus tôt les problèmes d'intégration.

Après chaque tâche, demandez à l'agent de résumer :

• Les fichiers qu'il a modifiés

• Le comportement qu'il a ajouté

• Les hypothèses qu'il a formulées

• Les tests qu'il a exécutés

• Les tests qui nécessitent encore un jugement humain

• Toute conséquence en matière de sécurité ou de déploiement

Exécutez l'application après chaque étape. Essayez d'abord le comportement attendu, puis utilisez-la de manière incorrecte. Soumettez des formulaires vides, des entrées surdimensionnées, des requêtes en double, des sessions expirées, des URL non valides et l'identifiant d'enregistrement d'un autre utilisateur.

Lorsqu'un élément échoue, signalez le comportement observé au lieu de demander à l'agent de « tout corriger ». Incluez la commande, le résultat attendu, le résultat réel et la sortie de journal pertinente. Des retours précis aident le modèle à distinguer un défaut d'une exigence mal comprise.

N'acceptez pas les réécritures générales comme réponse par défaut à un bug local. Demandez une explication de la cause racine et un correctif minimal. Les grandes modifications générées sont plus difficiles à examiner et peuvent supprimer des comportements fonctionnels.

Faites un commit après chaque étape vérifiée. Utilisez des descriptions qui indiquent la modification du produit, et non l'historique de la conversation. Un historique propre vous permet de revenir à un état connu lorsqu'un agent introduit plusieurs erreurs liées.

Démarrez une nouvelle session d'agent lorsque le contexte devient confus. Donnez à la nouvelle session la spécification, l'architecture, l'étape actuelle et l'état vérifié du dépôt. Les longues conversations peuvent conserver des hypothèses obsolètes après que le produit a changé.

Cette approche par étapes semble plus lente que la génération en une seule fois. En pratique, elle réduit le cycle coûteux où une application soignée s'effondre lors du déploiement. L'objectif n'est pas d'obtenir le maximum de code par invite, mais le maximum de progrès vérifiés par modification.

Le déploiement transforme une démonstration en système opérationnel

La mise en production ajoute des responsabilités d'infrastructure, d'identité, de réglementation et de récupération que l'agent de programmation ne peut pas assumer personnellement.

Une application locale s'exécute sur une seule machine dans des conditions favorables. Un déploiement public reçoit un trafic imprévisible, des requêtes mal formées, des analyses automatisées et des données réelles d'utilisateurs. Cet environnement change la signification de « fonctionnel ».

Séparez les environnements de développement et de production. Le développement est l'espace d'expérimentation. La production est le système dont dépendent les vrais utilisateurs. Ils ne doivent pas partager la même base de données, les mêmes identifiants ni un accès administratif non restreint.

Stockez la configuration au moyen de variables d'environnement ou d'un service de secrets géré. Ne placez jamais de mots de passe de base de données, de clés API ou de secrets de signature dans les fichiers source. Demandez à l'agent d'analyser l'historique du dépôt à la recherche d'identifiants accidentellement exposés avant le lancement.

Choisissez l'hébergement en fonction des composants de l'application. Une interface statique, un serveur de longue durée, une tâche planifiée et une base de données relationnelle ont des exigences différentes. Le plan de déploiement doit préciser comment chaque composant démarre, communique, consigne les erreurs et redémarre.

Un domaine ajoute une couche supplémentaire. Ses enregistrements DNS orientent les utilisateurs vers le service d'hébergement, tandis que TLS chiffre les connexions. Le produit a également besoin d'une stratégie pour rediriger les formes alternatives du domaine et renouveler les certificats.

Les produits hébergés en Chine continentale peuvent être soumis à des obligations supplémentaires de dépôt. Les règles révisées de la Chine relatives au dépôt ICP indiquent que les services d'information Internet non commerciaux fournis dans le pays doivent effectuer les procédures de dépôt.

Les règles indiquent également que les demandes complètes devraient recevoir une décision de dépôt dans les 20 jours ouvrables. Il s'agit d'un maximum réglementaire, et non d'une promesse que chaque lancement se terminera selon un calendrier fixe. Les créateurs devraient considérer le dépôt comme un chantier à lancer tôt.

L'obligation exacte dépend du service, de l'accord d'hébergement, du modèle économique et de la juridiction. Un agent de programmation peut organiser les exigences, mais il ne peut pas fournir d'autorisation juridique faisant autorité. Consultez le fournisseur concerné et un conseil juridique qualifié lorsque le périmètre est incertain.

Le déploiement nécessite également des contrôles de migration de base de données. Sauvegardez les données de production avant d'appliquer une modification destructive. Testez la migration sur des données représentatives et documentez la manière de l'annuler.

Créez une liste de contrôle de mise en production couvrant la réussite de la compilation, les tests automatisés, les contrôles de sécurité, les migrations, la configuration, la surveillance et le retour en arrière. Chaque élément doit produire des preuves plutôt qu'une assurance verbale de l'agent.

Les journaux doivent indiquer ce qui a échoué, quand cela a échoué et quelle opération a été affectée. Ils ne doivent pas exposer de mots de passe, de jetons, de documents privés ou d'informations personnelles inutiles. Consigner davantage de données n'est pas automatiquement plus sûr.

La surveillance doit couvrir la disponibilité de base, les erreurs de serveur, la latence, les tâches d'arrière-plan échouées et les limites de stockage. Une alerte a besoin d'un responsable humain et d'un chemin de réponse. Une notification que personne ne comprend n'est que du bruit supplémentaire.

Les sauvegardes nécessitent des tests de restauration. Une tâche de sauvegarde réussie prouve que les données ont été copiées quelque part. Elle ne prouve pas que le produit peut se rétablir dans un délai acceptable.

Avant d'inviter des utilisateurs, créez une voie de retour en arrière. Cela peut signifier restaurer la version précédente, désactiver une nouvelle fonctionnalité ou annuler une migration. L'équipe doit savoir quelle action s'applique à chaque défaillance probable.

C'est ici que la description « sans code » devient trompeuse. Le créateur ne saisit peut-être pas l'implémentation, mais il exploite tout de même un système comportant des responsabilités techniques et organisationnelles.

Le code généré par l'IA nécessite une protection des branches et des tests adversariaux

La confiance d'un agent ne prouve pas qu'un produit est sécurisé, correct ou prêt pour la production.

L'enquête 2025 Stack Overflow Developer Survey a révélé un écart de confiance clair concernant la production de l'IA. Bien que 84 % des personnes interrogées utilisaient ou prévoyaient d'utiliser des outils d'IA, 46 % se méfiaient de leur exactitude. Seuls 33 % ont exprimé leur confiance.

La même enquête auprès des développeurs a constaté que 66 % des personnes interrogées étaient frustrées par des solutions d’IA presque correctes. 45 % supplémentaires ont identifié le débogage chronophage du code généré comme une frustration majeure.

Ces chiffres ne montrent pas que les agents de codage manquent de valeur. Ils montrent pourquoi la vérification doit évoluer avec l’adoption. Une génération plus rapide peut créer une charge de révision plus importante lorsque les modifications s’étendent à des parties inconnues d’un système.

Protégez la branche principale après la configuration initiale du projet. La fonctionnalité de GitHub protection des branches peut exiger des pull requests, des vérifications de statut réussies, des discussions résolues ou des revues approuvées avant qu’une modification soit fusionnée.

Un créateur travaillant seul peut tout de même bénéficier de cette structure. L’agent travaille sur une branche distincte, les vérifications automatisées s’exécutent, et le créateur examine le résumé avant la fusion. Cette pause crée une frontière entre la génération et la publication.

Au minimum, le pipeline automatisé doit installer les dépendances à partir d’un fichier verrouillé, compiler l’application, exécuter les tests et effectuer des vérifications axées sur la sécurité. Un échec doit bloquer la fusion au lieu de devenir un avertissement enfoui dans les journaux.

Les tests doivent fonctionner à plusieurs niveaux :

• Les tests unitaires vérifient des règles métier isolées.

• Les tests d’intégration vérifient la communication avec les bases de données et les services externes.

• Les tests de bout en bout mettent à l’épreuve des parcours utilisateur complets.

• Les tests d’autorisation confirment qu’un compte ne peut pas accéder aux données d’un autre compte.

• Les tests de migration vérifient que les modifications du schéma préservent les enregistrements existants.

• Les tests manuels examinent la facilité d’utilisation, les résultats ambigus et les comportements inattendus.

Demandez à l’agent d’écrire des tests avant de corriger un défaut confirmé. Le test en échec capture le problème et réduit le risque qu’il réapparaisse. Exigez ensuite que ce même test réussisse après le correctif.

La sécurité exige une étape distincte de modélisation des menaces. Un modèle de menace identifie les ressources de valeur, les attaquants possibles, les points d’entrée exposés et les utilisations abusives probables. Il transforme « rendez-le sécurisé » en un ensemble de questions concrètes.

Que se passe-t-il si un utilisateur modifie un identifiant dans une requête ? Le contenu téléversé peut-il exécuter du code ? Des URL externes sont-elles récupérées par le serveur ? Des tentatives répétées de mot de passe peuvent-elles continuer sans limite ? Les routes administratives vérifient-elles les rôles sur le serveur ?

OWASP avertit que les systèmes générés par l’IA ou développés par des citoyens peuvent réutiliser des composants vulnérables et même référencer des paquets inexistants. Ses recommandations concernant les composants non fiables recommandent de traiter les dépendances générées comme des éléments nécessitant une vérification.

Inspectez chaque nouvelle dépendance. Confirmez que le paquet existe, qu’il provient de l’éditeur attendu, qu’il est maintenu et qu’il répond à un besoin nécessaire. Un nom de paquet plausible ne prouve pas sa légitimité.

Utilisez un fichier de verrouillage des dépendances et évitez les paquets inutiles. Moins de dépendances réduisent le nombre de composants externes susceptibles d’échouer, de changer de propriétaire ou d’introduire des vulnérabilités.

Le code d’authentification généré mérite un examen particulier. Le stockage des mots de passe, la gestion des sessions, les flux de réinitialisation, les paramètres des cookies et les vérifications d’autorisation comportent des détails sensibles sur le plan de la sécurité. Préférez des implémentations établies et documentées à une logique personnalisée.

N’utilisez jamais de véritables données clients lors des premiers tests. Générez des enregistrements synthétiques qui ressemblent à la structure nécessaire sans exposer d’informations personnelles. Limitez l’accès à la production, même lorsqu’une seule personne exploite le projet.

Les fonctionnalités d’IA créent des risques supplémentaires. Si le contenu d’un utilisateur entre dans une invite de modèle, traitez ce contenu comme non fiable. Il peut tenter de remplacer des instructions, révéler un contexte caché ou déclencher des outils involontaires.

Un agent disposant d’un accès aux fichiers et aux commandes possède également d’importants privilèges locaux. Examinez les actions demandées, restreignez les identifiants et évitez d’accorder l’accès à la production pendant le développement ordinaire. La commodité ne doit pas effacer les frontières opérationnelles.

Un fondateur non technique devrait organiser une revue indépendante avant de lancer un produit qui traite de l’argent, des informations de santé, des documents confidentiels ou des données d’identité sensibles. L’agent qui a généré le code ne devrait pas être le seul à examiner son propre travail.

Ce que les créateurs doivent surveiller après le lancement

Le test décisif du vibe coding n’est pas de savoir si un agent peut publier la version un, mais si l’humain peut exploiter la version deux.

Le premier signal est la fiabilité des changements. Suivez la fréquence à laquelle une fonctionnalité demandée réussit les tests, atteint la production et reste active sans annulation. Des retours en arrière fréquents suggèrent que l’architecture ou le processus de vérification ne peut pas soutenir la vitesse de l’agent.

Le deuxième signal est la responsabilité en cas d’incident. Lorsqu’une alerte apparaît, le créateur doit identifier le composant concerné, examiner les journaux pertinents et expliquer le chemin de défaillance. Une dépendance totale à la réponse d’un autre agent laisse le produit sans diagnostic responsable.

Le troisième signal est la portabilité des modèles. Kimi, Qwen, GLM et d’autres systèmes de codage continueront à modifier leurs clients, modèles, méthodes d’authentification et limites. Un dépôt doté d’une documentation claire et d’outils standard peut passer plus facilement d’un agent à un autre.

La portabilité des modèles ne signifie pas que chaque agent produit un code identique. Elle signifie que les exigences, l’architecture, les commandes et les tests du projet sont suffisamment explicites pour qu’un autre outil ou ingénieur puisse poursuivre le travail.

Les créateurs doivent également surveiller l’écart entre le résultat visible et la qualité opérationnelle. Les nouveaux écrans d’interface sont faciles à démontrer. Des taux d’erreur plus faibles, des migrations plus sûres, une récupération plus rapide et des autorisations plus claires sont moins visibles, mais plus importants.

Ce tutoriel de vibe coding avec Kimi se termine donc par une définition différente du succès. Le succès ne consiste pas à atteindre une URL en ligne sans toucher à un langage de programmation. Il consiste à atteindre un système en ligne dont vous pouvez expliquer le comportement, les données, les risques et le chemin de récupération.

Commencez par un parcours utilisateur et rédigez ses exigences avant d’ouvrir l’agent de codage. Demandez à l’agent de planifier, d’implémenter une étape et de fournir des preuves issues des tests. Validez uniquement les modifications vérifiées, puis mettez en place des contrôles de déploiement et de récupération avant d’inviter de vrais utilisateurs.

Si vous ne pouvez pas expliquer où l’identité est vérifiée, où les données résident ou comment une publication défaillante est annulée, interrompez le lancement. Demandez à l’agent de cartographier ces systèmes jusqu’à ce que les réponses deviennent claires. Le vibe coding peut réduire le coût de l’implémentation, mais il ne peut pas transférer la responsabilité du produit à un modèle.