Vibe coding : beau au lancement, fiable dans la durée ?
Un site généré par IA peut séduire au lancement. Découvrez ce qu'il faut vérifier pour pouvoir le gérer, le sécuriser et le faire évoluer dans la durée.
Sur cette page6 sections
Vous décrivez une idée, vous demandez un menu, une page de connexion et deux ou trois fonctionnalités, et quelques échanges plus tard vous avez déjà quelque chose à montrer. Il y a encore peu de temps, cette première version aurait demandé beaucoup plus de travail. Aujourd'hui, elle peut arriver assez vite pour donner envie de passer directement à la suite : le nom de domaine, la mise en ligne, les premiers clients.
Je comprends très bien l'intérêt. Pouvoir essayer une idée sans consacrer des semaines à sa fabrication, c'est précieux. Là où je décroche, c'est quand on considère que le logiciel est prêt parce que la démonstration est convaincante. Une démo montre que le chemin prévu fonctionne. Une entreprise va emprunter tous les autres.
Ce n'est pas la même chose que développer avec l'aide d'une IA tout en gardant la maîtrise du projet. On peut lui faire produire une interface, lui demander une explication ou préparer des tests, puis relire ce qu'elle propose et l'intégrer à une architecture qu'on comprend. La différence ne se voit pas forcément sur la capture d'écran. Elle se voit quand il faut intervenir.
Un peu comme monter un meuble : suivre une notice, vérifier les fixations et savoir pourquoi telle pièce porte le poids, ce n'est pas simplement obtenir quelque chose qui tient debout. L'IA peut accélérer énormément le montage. Elle ne retire pas la responsabilité de vérifier la solidité avant de poser votre activité dessus.
Si ces besoins ont été prévus, il ouvre son administration et le fait. Si les produits ont été écrits directement dans le code pour aller vite, il faut maintenant fabriquer ce qui aurait dû permettre de les gérer. Ce n'est pas un petit bouton oublié : c'est la manière dont le site organise ses informations qu'il faut reprendre.
On retrouve le même sujet avec les réservations. Afficher un créneau disponible est facile à démontrer. Savoir ce qui se passe quand deux personnes le choisissent presque en même temps, quand un paiement échoue ou quand la confirmation ne part pas, c'est un autre travail. Le problème apparaît justement au moment où le site commence à servir.
L'enjeu n'est donc pas d'avoir tout prévu, ce qui serait impossible. C'est de construire une base qui permet de traiter ces situations sans défaire chaque fois ce qui fonctionnait la veille.
Le serveur doit vérifier que votre compte a le droit d'accéder à cette facture, à chaque demande. Cacher un bouton dans l'interface ne suffit pas non plus à interdire une opération. Ces contrôles ne sont pas spectaculaires, mais ils font partie du produit autant que ses couleurs ou son menu.
Ce n'est pas une faiblesse réservée au code généré : un développeur peut aussi se tromper. La question est de savoir qui cherche ces erreurs et comment elles sont corrigées. La documentation de GitHub sur les suggestions de Copilot rappelle elle-même que le code proposé doit être revu et testé. Une réponse bien présentée n'est pas une validation technique.
Sur un projet que personne ne maîtrise, on peut se retrouver à demander une correction à l'IA, constater qu'un autre écran ne fonctionne plus, puis demander une correction de la correction. Chaque essai semble rapprocher du résultat, jusqu'au moment où l'on ne sait plus ce qu'on a changé pour résoudre quoi.
L'historique du code, les tests et un environnement séparé de la production servent précisément à éviter cette situation. Ils permettent de comparer, de reproduire et de revenir à une version connue. La maintenance d'un site commence par cette capacité à intervenir sans jouer à pile ou face avec les demandes du client.
Puis posez une question moins confortable : « Si une mise à jour casse cette fonction, comment on repart ? » Une réponse utile parle d'une sauvegarde, d'une version précédente, de vérifications et d'un interlocuteur. Pas seulement de la possibilité de redemander à l'IA.
Demandez aussi ce qu'un autre développeur récupérerait si vous changiez de prestataire : code, documentation, données, accès à l'hébergement et au domaine. Un projet qui ne peut être repris que par la personne qui se souvient de ses conversations avec l'IA vous rend dépendant d'une mémoire, pas seulement d'une compétence.
Chez Cadarsir, le sur-mesure ne signifie pas réinventer les fondations à chaque projet. On s'appuie sur une base connue pour adapter le site au fonctionnement de l'entreprise. L'IA peut aider dans ce travail ; elle ne décide pas à notre place de ce qui est suffisamment fiable pour être livré.
Une première version rapide peut être un excellent début. Mais avant d'en faire votre outil de travail, vérifiez qu'une personne saura encore vous expliquer ce qui se passe derrière l'écran quand vous aurez besoin de changer autre chose que la couleur d'un bouton.
Je comprends très bien l'intérêt. Pouvoir essayer une idée sans consacrer des semaines à sa fabrication, c'est précieux. Là où je décroche, c'est quand on considère que le logiciel est prêt parce que la démonstration est convaincante. Une démo montre que le chemin prévu fonctionne. Une entreprise va emprunter tous les autres.
Le problème n'est pas de travailler avec une IA
Le vibe coding consiste, dans son sens courant, à décrire ce qu'on veut à une IA et à faire avancer le projet en regardant surtout le résultat. On demande une modification, on teste, on reformule. Selon la manière de travailler, on peut finir avec beaucoup de code dont on n'a pas vraiment étudié le fonctionnement.Ce n'est pas la même chose que développer avec l'aide d'une IA tout en gardant la maîtrise du projet. On peut lui faire produire une interface, lui demander une explication ou préparer des tests, puis relire ce qu'elle propose et l'intégrer à une architecture qu'on comprend. La différence ne se voit pas forcément sur la capture d'écran. Elle se voit quand il faut intervenir.
Un peu comme monter un meuble : suivre une notice, vérifier les fixations et savoir pourquoi telle pièce porte le poids, ce n'est pas simplement obtenir quelque chose qui tient debout. L'IA peut accélérer énormément le montage. Elle ne retire pas la responsabilité de vérifier la solidité avant de poser votre activité dessus.
Le lendemain du lancement, quelqu'un veut changer un prix
Prenons une petite boutique en ligne. Vingt produits, de belles photos, un panier qui fonctionne. Jusque-là, tout va bien. Puis le commerçant veut changer un prix, masquer un produit épuisé et ajouter une nouvelle référence sans appeler son prestataire.Si ces besoins ont été prévus, il ouvre son administration et le fait. Si les produits ont été écrits directement dans le code pour aller vite, il faut maintenant fabriquer ce qui aurait dû permettre de les gérer. Ce n'est pas un petit bouton oublié : c'est la manière dont le site organise ses informations qu'il faut reprendre.
On retrouve le même sujet avec les réservations. Afficher un créneau disponible est facile à démontrer. Savoir ce qui se passe quand deux personnes le choisissent presque en même temps, quand un paiement échoue ou quand la confirmation ne part pas, c'est un autre travail. Le problème apparaît justement au moment où le site commence à servir.
L'enjeu n'est donc pas d'avoir tout prévu, ce qui serait impossible. C'est de construire une base qui permet de traiter ces situations sans défaire chaque fois ce qui fonctionnait la veille.
Un écran de connexion ne suffit pas à protéger les données
Une page qui demande un mot de passe donne facilement une impression de sécurité. Mais imaginez que vous consultiez votre facture et que son adresse contienne un numéro. Si changer ce numéro vous permet de voir celle d'un autre client, la page de connexion n'a pas réglé le vrai problème.Le serveur doit vérifier que votre compte a le droit d'accéder à cette facture, à chaque demande. Cacher un bouton dans l'interface ne suffit pas non plus à interdire une opération. Ces contrôles ne sont pas spectaculaires, mais ils font partie du produit autant que ses couleurs ou son menu.
Ce n'est pas une faiblesse réservée au code généré : un développeur peut aussi se tromper. La question est de savoir qui cherche ces erreurs et comment elles sont corrigées. La documentation de GitHub sur les suggestions de Copilot rappelle elle-même que le code proposé doit être revu et testé. Une réponse bien présentée n'est pas une validation technique.
La première modification urgente raconte beaucoup de choses
Votre campagne démarre demain. Il faut changer un formulaire et envoyer les demandes vers un nouvel outil. Sur un projet compris, on repère les parties concernées, on prépare la modification et on vérifie les fonctions qui pourraient être affectées.Sur un projet que personne ne maîtrise, on peut se retrouver à demander une correction à l'IA, constater qu'un autre écran ne fonctionne plus, puis demander une correction de la correction. Chaque essai semble rapprocher du résultat, jusqu'au moment où l'on ne sait plus ce qu'on a changé pour résoudre quoi.
L'historique du code, les tests et un environnement séparé de la production servent précisément à éviter cette situation. Ils permettent de comparer, de reproduire et de revenir à une version connue. La maintenance d'un site commence par cette capacité à intervenir sans jouer à pile ou face avec les demandes du client.
Demandez à voir autre chose que la page d'accueil
Vous n'avez pas besoin de lire le code pour choisir un prestataire. En revanche, vous pouvez lui demander de vous montrer comment vous ajouterez un produit, ce qu'un collaborateur pourra modifier et comment une demande sera retrouvée dans l'administration.Puis posez une question moins confortable : « Si une mise à jour casse cette fonction, comment on repart ? » Une réponse utile parle d'une sauvegarde, d'une version précédente, de vérifications et d'un interlocuteur. Pas seulement de la possibilité de redemander à l'IA.
Demandez aussi ce qu'un autre développeur récupérerait si vous changiez de prestataire : code, documentation, données, accès à l'hébergement et au domaine. Un projet qui ne peut être repris que par la personne qui se souvient de ses conversations avec l'IA vous rend dépendant d'une mémoire, pas seulement d'une compétence.
Aller plus vite, oui, mais pour arriver où
Je ne vois aucun intérêt à refuser un outil qui peut accélérer le travail. Ce qui m'intéresse, c'est ce qu'on fait du temps gagné : mieux vérifier le parcours, prendre le temps de comprendre le besoin ou rendre l'administration réellement utilisable.Chez Cadarsir, le sur-mesure ne signifie pas réinventer les fondations à chaque projet. On s'appuie sur une base connue pour adapter le site au fonctionnement de l'entreprise. L'IA peut aider dans ce travail ; elle ne décide pas à notre place de ce qui est suffisamment fiable pour être livré.
Une première version rapide peut être un excellent début. Mais avant d'en faire votre outil de travail, vérifiez qu'une personne saura encore vous expliquer ce qui se passe derrière l'écran quand vous aurez besoin de changer autre chose que la couleur d'un bouton.
