Vibe coding : beau au lancement, fiable dans la durée ?

Une consigne bien formulée, quelques échanges avec un agent IA, et un site peut prendre forme en quelques heures. La page est propre. Les boutons fonctionnent. Le résultat donne parfois l’impression qu’un projet web complexe est devenu presque automatique.

C’est une vraie avancée. Mais pour une entreprise, la bonne question n’est pas seulement : « Est-ce que le site fonctionne aujourd’hui ? » C’est aussi : « Qui saura encore le comprendre, le sécuriser et le faire évoluer demain ? »

Le problème n’est donc pas l’intelligence artificielle. Le risque apparaît lorsque la vitesse de génération est confondue avec la maîtrise du produit livré.

Le vibe coding, c’est quoi exactement ?

Le terme désigne une façon de créer un logiciel en décrivant le résultat attendu à une IA, puis en la laissant produire une grande partie du code. On teste, on reformule, on corrige et on avance par itérations, parfois sans lire ni comprendre chaque ligne générée.

Pour une maquette, un prototype interne ou un outil temporaire, cette approche peut être très utile. Elle permet d’explorer une idée rapidement et de réduire le temps passé sur certaines tâches répétitives.

Elle peut aussi aider un développeur expérimenté. Dans ce cas, l’IA agit comme un accélérateur : la personne qui l’utilise sait vérifier l’architecture, repérer une incohérence, écrire des tests, protéger les données et reprendre la main lorsque la génération s’égare.

La situation est différente quand personne ne comprend réellement ce qui a été construit. Le site peut alors sembler terminé alors que les choix les plus importants — droits d’accès, sauvegardes, structure des données, capacité d’évolution — n’ont pas été pensés.

Une belle façade ne dit pas comment le site est construit

Un visiteur voit une interface. Une entreprise dépend, elle, de tout ce qui se trouve derrière.

Prenons un e-commerce d’une vingtaine de produits. Au lancement, les fiches sont jolies et le paiement fonctionne. Puis le client demande quelque chose de très normal : pouvoir modifier un prix, remplacer une photo, gérer un stock ou ajouter un produit depuis un espace d’administration.

Si le projet a été conçu comme une suite de pages figées, cette demande banale devient soudain un chantier. Le prestataire découvre qu’il n’a pas prévu de véritable modèle de données ni de back-office. Il doit bricoler une nouvelle couche, refaire une partie du site ou expliquer au client qu’il devra repasser par lui pour chaque changement.

Ce n’est pas un problème d’âge, de diplôme ou d’outil. C’est un problème d’anticipation du métier.

Un développeur professionnel ne pense pas uniquement à la page visible. Il se demande aussi :

• qui a le droit de consulter, modifier ou supprimer une information ;
• comment les contenus seront administrés au quotidien ;
• où les données sont stockées et comment elles sont sauvegardées ;
• ce qui se passe si un paiement, un import ou un envoi d’e-mail échoue ;
• comment corriger une fonction sans en casser une autre ;
• comment un second développeur pourra reprendre le projet.

Ces questions sont moins spectaculaires qu’une animation réussie. Pourtant, ce sont elles qui déterminent si le site devient un outil de travail ou une dépendance fragile.

Le vrai test arrive souvent après la mise en ligne

Un site professionnel vit. Une campagne démarre, une offre change, un collaborateur quitte l’entreprise, une obligation réglementaire évolue ou une intégration externe modifie son fonctionnement.

Imaginez une campagne Google Ads déjà programmée. À la dernière minute, il faut adapter une page d’atterrissage, changer un formulaire et ajouter un suivi de conversion. Le prestataire ouvre le projet, demande à l’IA de modifier ce qu’elle avait généré, puis constate que le nouveau code casse le formulaire mobile ou une autre page.

Le délai commercial est réel, mais personne ne sait localiser proprement la régression. La correction devient une succession d’essais. Le client ne paie plus seulement une modification : il paie l’absence de maîtrise accumulée depuis le départ.

C’est ici que la maintenabilité prend tout son sens. Un site maintenable n’est pas un site qui ne rencontre jamais de bug. C’est un site dont l’équipe peut comprendre le fonctionnement, isoler un problème, tester une correction et la déployer avec un risque maîtrisé.

Ce que l’IA sait très bien faire — et ce qu’elle ne garantit pas

Les agents IA sont déjà capables de produire des interfaces, d’expliquer du code, de proposer des tests, de générer une base de projet ou de suggérer une correction. Entre de bonnes mains, ils peuvent faire gagner un temps précieux.

Mais une réponse générée n’apporte pas, à elle seule, la preuve que :

• les autorisations sont correctement séparées entre un administrateur, un salarié et un client ;
• les données sensibles sont protégées ;
• les sauvegardes existent et peuvent réellement être restaurées ;
• les dépendances utilisées seront maintenues ;
• le projet tient la charge attendue ;
• les erreurs sont surveillées ;
• les choix techniques sont documentés ;
• la prochaine évolution pourra être ajoutée sans tout reconstruire.

Les référentiels de développement sécurisé, comme celui du NIST, décrivent d’ailleurs la qualité logicielle comme un ensemble de pratiques réparties sur tout le cycle de vie : préparation, protection, production et traitement des vulnérabilités. Générer du code n’est qu’une partie de ce travail.

Même les études sur la productivité des outils IA invitent à la nuance. Les résultats dépendent du contexte, de la maturité du projet, de l’expérience de l’utilisateur et de la tâche. Sur un code existant et complexe, un outil peut accélérer certaines étapes tout en ajoutant du temps de vérification ou de reprise. La bonne question n’est donc pas « l’IA est-elle rapide ? », mais « qui contrôle la qualité de ce qu’elle produit ? ».

Débutant formé et prestataire sans maîtrise : ce n’est pas la même chose

Un développeur junior peut faire des erreurs. Un senior aussi. La différence ne tient pas à une prétendue perfection.

Une personne formée possède normalement des repères : séparation des responsabilités, contrôle des entrées, gestion des accès, versionnement, tests, logs, sauvegardes, documentation. Elle sait surtout qu’il existe des sujets qu’elle doit approfondir avant de livrer.

À l’inverse, quelqu’un peut obtenir rapidement un résultat visuel impressionnant sans percevoir ce qui manque. Le danger n’est pas d’utiliser l’IA ou d’être autodidacte. Il est de vendre comme « prêt pour l’entreprise » un produit que personne ne sait auditer, expliquer ou maintenir.

Comment reconnaître un prestataire capable de maintenir ce qu’il livre

Avant de choisir un prestataire, il n’est pas nécessaire de devenir expert technique. Quelques questions concrètes permettent déjà de distinguer une démonstration séduisante d’un projet réellement préparé.

1. « Comment vais-je modifier mes contenus ? »

Demandez une démonstration du back-office avec vos cas réels : modifier une fiche, ajouter un utilisateur, corriger un prix, remplacer une image ou consulter une demande client.

2. « Que se passe-t-il si une modification casse quelque chose ? »

Le prestataire doit pouvoir expliquer son processus : environnement de test, versionnement, sauvegarde avant intervention, vérification et retour arrière.

3. « Qui possède le nom de domaine, l’hébergement, les comptes et les données ? »

Les accès importants doivent être identifiés, transmissibles et protégés. Votre activité ne devrait pas dépendre d’un compte personnel inaccessible.

4. « Comment sont gérés les droits d’accès ? »

Un éditeur de contenu ne devrait pas disposer automatiquement des mêmes pouvoirs qu’un administrateur. Les fonctions sensibles doivent être réservées aux bons rôles.

5. « Les sauvegardes sont-elles testées ? »

Une sauvegarde annoncée n’est pas forcément une sauvegarde restaurable. Demandez la fréquence, le lieu de stockage, la durée de conservation et la procédure de restauration.

6. « Comment un autre développeur reprendrait-il le projet ? »

Documentation, dépôt de code, historique des changements, conventions et procédure de déploiement sont de bons signaux. La réponse « il suffira de redemander à l’IA » n’en est pas un.

7. « Comment estimez-vous une évolution urgente ? »

Un professionnel doit pouvoir identifier les zones touchées, les risques, les tests nécessaires et un délai réaliste. Il peut dire qu’une demande est complexe ; il doit pouvoir expliquer pourquoi.

8. « Où l’intelligence artificielle intervient-elle dans votre méthode ? »

L’usage de l’IA n’a rien de honteux. Une réponse transparente est préférable : génération initiale, aide au diagnostic, rédaction de tests, documentation ou revue. Demandez surtout qui valide le résultat final.

Une stack éprouvée ne remplace pas le sur-mesure : elle le rend plus fiable

Chez Cadarsir, les projets ne repartent pas d’une page blanche improvisée à chaque demande. La stack a été construite et éprouvée pendant plus de six ans, puis enrichie au fil de besoins réels : administration des contenus, gestion des rôles, maintenance, sauvegardes, évolutions métier et suivi dans la durée.

Cela ne signifie pas que tous les sites sont identiques ni qu’aucun défaut ne peut survenir. Cela signifie que les fondations importantes sont connues, documentées et maîtrisées. Le temps gagné ne vient pas du fait d’ignorer l’architecture, mais du fait de réutiliser une architecture comprise.

L’objectif est de proposer aux TPE et PME un niveau d’exigence souvent associé à des projets de plus grande taille, sans leur imposer une usine à gaz : un vrai espace d’administration, des fonctions pensées pour leur activité et un interlocuteur capable de faire évoluer le site lorsqu’une priorité change.

Le bon critère n’est pas « avec ou sans IA »

Opposer les développeurs à l’intelligence artificielle serait une erreur. Les bons professionnels utilisent déjà de nombreux outils pour travailler plus vite et mieux. L’IA en fait partie.

Le choix d’un prestataire devrait plutôt reposer sur trois questions : comprend-il ce qu’il construit, peut-il le prouver, et saura-t-il encore intervenir lorsque votre entreprise aura changé ?

Un site réussi n’est pas seulement beau le jour de sa livraison. Il reste administrable, explicable et évolutif quand arrive la première vraie demande imprévue.