Vibe coding : quand l’utiliser, où sont ses limites et quand passer à une agence ?
Le vibe coding est une excellente façon de commencer. Pas toujours de continuer seul.
ChatGPT Canvas, Claude Artifacts, Lovable, Bolt ou Replit peuvent transformer une idée en interface interactive en quelques heures. C'est un progrès réel : on peut montrer, essayer et corriger bien avant d'engager un développement complet. La limite apparaît lorsque cette démonstration devient un produit dont des personnes, des données ou une activité commencent à dépendre.
Le débat est souvent caricatural. D'un côté, le vibe coding serait réservé aux jouets. De l'autre, il rendrait les développeurs inutiles. Ces deux positions confondent la vitesse de création avec la responsabilité d'exploitation.
Une maquette fonctionnelle et une application de production ne répondent pas au même problème. La première aide à apprendre. La seconde doit continuer à fonctionner lorsque l'utilisateur se trompe, que le réseau coupe, qu'une dépendance change ou qu'une personne malveillante cherche une faille.
Le même outil peut servir deux pratiques très différentes
La frontière utile ne passe ni entre l'IA et le code écrit à la main, ni entre un outil no-code et un IDE. Elle passe par ce qui est réellement vérifié et par la personne qui accepte d'en répondre.
Vibe coding
Vous décrivez le résultat attendu, essayez ce qui est généré et poursuivez tant que l'interface semble fonctionner. C'est adapté lorsque l'erreur est visible, réversible et peu coûteuse.
Développement assisté par IA
Les mêmes modèles accélèrent le travail, mais l'architecture, les permissions, les données, les tests et les déploiements sont relus et compris par une personne qui peut intervenir sans dépendre du prochain prompt.
Appik Studio ne travaille pas contre l'IA. Nous l'utilisons pour aller plus vite, avec un cadre d'ingénierie qui transforme une réponse plausible en résultat vérifiable.
Quand le vibe coding est le bon outil
Il apporte le plus de valeur lorsqu'il raccourcit une boucle d'apprentissage, sans créer une dépendance difficile à reprendre.
Rendre une idée visible
Un écran interactif aligne mieux une équipe, un investisseur ou un futur utilisateur qu'une longue description. Les incompréhensions apparaissent tôt, quand elles coûtent encore peu.
Données fictives et aucun engagement opérationnel.
Tester un parcours
On peut vérifier si une inscription, une réservation ou un tableau de bord est compréhensible avant de choisir l'architecture définitive.
Le test valide l'usage, pas encore la sécurité ni la robustesse.
Automatiser un besoin local
Un calculateur, un outil personnel ou une petite interface interne peuvent rester simples si leurs erreurs sont faciles à repérer et n'affectent pas des données sensibles.
Peu d'utilisateurs, impact limité et solution de secours évidente.
Préparer un meilleur cahier des charges
Le prototype révèle les vrais écrans, les règles métier oubliées et les questions que personne n'avait formulées. Même si son code n'est pas conservé, cet apprentissage reste précieux.
Le prototype est traité comme une hypothèse, pas comme une fondation acquise.
La bonne question : que se passe-t-il si le logiciel se trompe ?
La taille du projet est un mauvais indicateur. Une petite page d'administration peut être plus critique qu'une grande application de démonstration. Évaluez les conséquences, la réversibilité et la personne responsable.
Erreur visible et réversible
Vous apprenez plus vite que vous n'accumulez de risque. Le vibe coding peut rester l'outil principal.
- Maquette ou démonstration
- Outil personnel sans données sensibles
- Expérience avec des données fictives
De vraies personnes commencent à dépendre du produit
Une revue ciblée évite que le prototype ne devienne silencieusement l'infrastructure de l'entreprise.
- Comptes utilisateurs et rôles
- Premières données clients
- Intégrations ou automatisations métier
L'erreur devient coûteuse, sensible ou difficile à annuler
Le produit a besoin d'une responsabilité technique explicite, de contrôles reproductibles et d'un plan d'exploitation.
- Paiements ou opérations irréversibles
- Données médicales, financières ou personnelles sensibles
- Service critique pour une équipe ou des clients
Tant qu'une erreur est facile à détecter, réversible et peu coûteuse, continuer seul peut être rationnel. Lorsque des utilisateurs, des données, de l'argent ou une activité en dépendent, le niveau de preuve doit changer.
Ce qu'une démonstration réussie ne prouve pas
Un écran qui fonctionne sur le parcours prévu ne dit presque rien sur les situations imprévues. Le passage en production consiste à remplacer ces inconnues par des contrôles.
Sécurité et accès aux données
Les permissions doivent être imposées côté serveur, les secrets rester hors du navigateur et chaque rôle ne voir que ce qui lui appartient. Il faut aussi examiner les fichiers envoyés, les dépendances et les fournisseurs d'IA qui reçoivent du contexte.
Architecture et maintenance
Une IA peut résoudre chaque demande locale tout en créant un ensemble incohérent. Une architecture durable reste compréhensible, documentée, construite avec des technologies répandues et reprenable par une autre équipe.
Tests et déploiement continu
La CI/CD ne prévient pas les régressions par magie. Elle devient utile lorsque les parcours critiques — connexion, paiement, permissions, synchronisation — disposent de tests qui bloquent réellement une livraison défectueuse.
Observabilité, analytics et alertes
Une erreur découverte seulement lorsqu'un client écrit n'est pas monitorée. Un outil comme Sentry doit relier les incidents aux versions et alerter une personne identifiée. Des alertes de sécurité doivent aussi signaler les secrets exposés, les dépendances vulnérables ou les accès anormaux. Une analytics produit comme PostHog aide à voir les parcours réellement utilisés. Logs, replays et événements doivent toutefois masquer les données sensibles, limiter la collecte et respecter le consentement ainsi que la durée de conservation prévue.
Sauvegardes, retour arrière et continuité
Il faut pouvoir restaurer les données et revenir à une version stable ; une sauvegarde qui n'a jamais été restaurée reste une hypothèse. Le client doit aussi contrôler le dépôt, les comptes, les domaines, les environnements et la documentation. Si le créateur initial ou l'outil disparaît, le produit ne doit pas disparaître avec lui.
Cas réels et accessibilité
Les utilisateurs n'ont pas tous le même appareil, la même connexion ou la même manière d'interagir. Clavier, lecteur d'écran, petits écrans, erreurs de saisie et interruptions font partie du produit, pas de la finition facultative.
Une stack solide n'est pas une liste de logos. C'est un produit que l'on peut expliquer, tester, déployer, observer, restaurer et transmettre.
En Suisse, la localisation des serveurs n'est qu'une partie de la réponse
La LPD révisée s'applique au traitement de données personnelles en Suisse. Le RGPD peut également s'appliquer selon les personnes concernées, le marché visé et les traitements réalisés. Une application sérieuse doit donc savoir quelles données elle collecte, pourquoi, où elles circulent, qui y accède et combien de temps elles sont conservées.
Appik peut déployer une infrastructure en Suisse lorsque la souveraineté ou les exigences du client le justifient. Mais une base de données suisse ne suffit pas si des journaux, des emails, des outils d'analyse ou un modèle d'IA transfèrent ensuite les mêmes données ailleurs.
Héberger en Suisse peut être un choix pertinent. Ce n'est pas un certificat de sécurité.
La décision doit suivre la cartographie des données, les sous-traitants autorisés, les sauvegardes, les accès et les obligations contractuelles — pas une promesse géographique isolée.
Dix ans de code manuel rendent l'IA plus utile, pas moins
J'ai développé, débogué et maintenu des applications pendant plus de dix ans avant l'arrivée des agents IA. Cette expérience permet de reconnaître plus vite une abstraction inutile, une permission trop large, une dépendance fragile ou un correctif qui masque le vrai problème.
Aujourd'hui, nous déléguons à l'IA une part importante de la génération, des tests, de la documentation et de l'analyse. Le gain de vitesse est réel. Mais la décision de conserver une architecture, de publier une migration ou d'accepter un risque reste humaine.
“L'expérience ne sert pas à écrire chaque ligne plus lentement. Elle sert à savoir ce que l'on peut déléguer, comment le vérifier et quand reprendre la main.”
Gaspard Chevassus
Fondateur d'Appik Studio · Développeur mobile et web depuis plus de 10 ans
Après le lancement, l'autonomie du client compte autant que le code
Un produit durable ne se limite pas à recevoir des mises à jour. Les utilisateurs doivent obtenir une réponse et l'équipe cliente doit pouvoir reprendre la conversation sans dépendre d'Appik pour chaque demande.
- 1
L'IA répond depuis le contexte du produit
ConvChat utilise les instructions et la FAQ propres au client pour traiter les demandes courantes. En mode BYOK, le client connecte le fournisseur et le modèle qu'il a approuvés.
- 2
L'équipe cliente garde la main
Ses collaborateurs accèdent à la boîte de réception, voient l'historique et reprennent les cas que l'assistant ne peut pas résoudre. L'IA n'est pas un mur entre l'utilisateur et une personne.
- 3
Appik intervient au niveau technique
Lorsqu'un problème exige une correction du produit ou de l'infrastructure, Appik peut intervenir dans le cadre d'un contrat de maintenance distinct. Le support humain illimité n'est pas présenté comme gratuit.
ConvChat est déjà intégré à des produits comme Le Pool et Smatch. Son utilisation est incluse pour les clients Appik, avec accès pour leurs propres membres du support.
L'accès à ConvChat est inclus ; la consommation du fournisseur d'IA BYOK et les interventions techniques d'Appik restent sous le contrôle du client et de son contrat.
Pouvez-vous encore continuer seul ?
Répondez honnêtement à ces questions. Un seul oui ne condamne pas le projet, mais il indique qu'une revue extérieure peut éviter une décision coûteuse.
- Des utilisateurs ou des collaborateurs dépendent-ils déjà du produit pour travailler ?
- Traitez-vous des données personnelles, confidentielles, médicales ou financières ?
- L'application gère-t-elle des paiements, des permissions ou une opération difficile à annuler ?
- Êtes-vous incapable d'expliquer précisément qui peut lire ou modifier chaque donnée ?
- Une correction récente a-t-elle cassé une fonctionnalité qui semblait sans rapport ?
- Disposez-vous d'un environnement de test séparé et d'un retour arrière reproductible ?
- Vos sauvegardes ont-elles déjà été restaurées avec succès ?
- Une personne identifiée reçoit-elle des alertes techniques et de sécurité exploitables, puis sait-elle corriger un incident de production ?
- Avez-vous vérifié que les logs, analytics et replays ne capturent pas de données sensibles inutiles ?
Si le produit a changé de catégorie, il ne faut pas nécessairement le réécrire. Il faut d'abord déterminer ce qui peut rester, ce qui doit être consolidé et qui en assumera la suite.
Questions fréquentes
Le vibe coding convient-il à un projet professionnel ?
Oui, surtout pour explorer un besoin, tester un parcours ou créer un outil à faible risque. Le caractère professionnel du projet ne dépend pas de l'outil utilisé, mais des conséquences d'une erreur et des contrôles mis en place.
Faut-il réécrire une application créée avec ChatGPT, Claude ou Lovable ?
Pas automatiquement. Les interfaces, les parcours et certaines couches peuvent souvent être conservés. La décision doit être prise après un audit par couche : données, authentification, logique métier, frontend et exploitation.
Un hébergement suisse garantit-il la conformité à la LPD ?
Non. Il peut répondre à une exigence de résidence ou de souveraineté, mais la conformité dépend aussi des finalités, des accès, des sous-traitants, des transferts, de la conservation et des mesures de sécurité.
Une agence qui utilise l'IA fait-elle aussi du vibe coding ?
Elle peut utiliser les mêmes modèles, mais la pratique change lorsque le code est compris, relu, testé et exploité sous la responsabilité d'une équipe. L'IA accélère alors l'ingénierie au lieu de la remplacer.
Quand faut-il demander un avis extérieur ?
Avant que le produit ne devienne critique : dès l'arrivée de vrais utilisateurs, de données sensibles, de paiements ou d'intégrations métier. Une revue courte à ce moment coûte moins cher qu'une reprise après incident.
Sources utiles
NCSC — Vibe coding spectrum
Un cadre de supervision proportionné au risque et à l'autonomie accordée aux outils IA.
OpenAI — ChatGPT Canvas
Documentation officielle sur l'édition de code et le rendu React/HTML dans Canvas.
Anthropic — Claude Artifacts
Documentation officielle sur la création et le partage de prototypes et d'applications interactives.
PFPDT — bases légales de la protection des données
Références officielles relatives à la Loi fédérale révisée sur la protection des données.
Sentry — alertes
Documentation officielle sur les alertes liées aux erreurs, aux métriques et aux versions.
PostHog — confidentialité
Contrôles de collecte, de traitement, de stockage et de masquage pour les analytics et replays.
Vous n'avez pas besoin d'un devis pour savoir si votre projet a changé de catégorie.
Lors d'un premier échange gratuit de 30 minutes, nous examinons le contexte, les utilisateurs, les données et le prochain jalon. Nous vous dirons franchement si vous pouvez continuer seul, si quelques points doivent être consolidés ou si un audit technique est justifié. Si un audit complet est pertinent, il fait l'objet d'une proposition payante séparée, avec un périmètre et des livrables explicites.
Swiss Made Software
