Vibely : ouvrir le vibe coding à tous, sans perdre le contrôle
Philippe Auriach et Pierre Sisson ont construit la plateforme de vibe coding interne de Mobsuccess. Architecture à deux couches, garde-fous, et ce qui change quand la question passe de « quel ROI ? » à « pourquoi pas ? ».
L’Intelligence Artificielle change aujourd’hui profondément nos métiers. Parmi tous ces bouleversements, un phénomène émerge : le vibe coding, une approche du développement logiciel qui place l’intuition et le besoin métier au centre. On s’adresse à un agent IA en langage naturel, qui produit ensuite le code.
Là où seulement 0,3 % de la population sait coder, ce blocage est levé : quiconque a une idée peut bâtir une application. Un gain d’agilité pour les entreprises, et un risque de chaos technique si l’accélération n’est pas orchestrée.
Quand le temps de création d’un prototype passe de plusieurs jours à quelques heures, comment gérer cette accélération tout en garantissant des produits aussi fiables, performants et sécurisés qu’avant ?
Pour encadrer cette pratique, Mobsuccess a créé Vibely, une plateforme interne sécurisée. L’utilisateur décrit son projet en langage naturel à un assistant. L’IA génère le code en temps réel dans un environnement isolé, et le résultat s’affiche instantanément.
Une fois l’outil prêt, il se publie en un clic sur un nom de domaine dédié (mobsuccess.ai), avec l’authentification et les bonnes pratiques logicielles qui vont avec. Le vibe coding sans les risques qui vont avec la pratique.
La preuve : 38 projets déployés en production en 2 mois.
Pour en parler, nous recevons Philippe Auriach et Pierre Sisson, qui ont développé cette plateforme interne.
Pour commencer, pourriez-vous vous présenter ?
Philippe — Je suis Philippe, architecte technique senior chez Mobsuccess depuis août 2021. Je suis responsable de la conception, de la cohérence et de l’évolution de l’architecture technique de la plateforme Mobsuccess, avec un rôle transversal entre vision produit et exécution technique.
Pierre — Je suis Pierre, Director of Engineering chez Mobsuccess depuis octobre 2020. Aujourd’hui, je pilote les équipes et les projets techniques, avec un rôle transverse entre management, exécution et stratégie. Plus récemment, j’accompagne le pivot autour de la GenAI, aussi bien dans les équipes tech que métier.
Parlez-nous de Vibely, la plateforme de vibe coding de Mobsuccess
Pierre — Vibely, c’est une plateforme web interne qui permet à n’importe qui chez Mobsuccess de créer des applications Next.js en décrivant son projet en langage naturel. On discute avec un assistant IA, il code dans un environnement isolé, on voit le résultat en temps réel dans un aperçu, et quand c’est prêt on publie en un clic.
L’idée c’est de rendre la création d’outils internes accessible à tout le monde, pas uniquement aux développeurs.
Quelles sont les origines de ce projet ? Pourquoi avez-vous voulu créer une plateforme dédiée développée en interne ?
Philippe — On avait un constat simple : beaucoup d’équipes métier avaient des besoins d’outils internes, dashboards, petites apps de gestion, automatisations, mais la bande passante dev était limitée.
Avec l’arrivée du vibe coding, on s’est dit que c’était l’occasion de démocratiser ça. Plutôt que d’utiliser des solutions externes qui posent des questions de sécurité, de données, de coûts et de personnalisation, on a préféré construire notre propre plateforme, intégrée à notre environnement (authentification Mobsuccess, déploiement interne, stack technique maîtrisée).
Ça nous donne un contrôle total sur l’expérience et la qualité de ce qui est produit.
Pour ceux qui ne sont pas familiers avec le terme, qu’est-ce que le vibe coding ?
Pierre — Chez Mobsuccess, on distingue en réalité trois formes de vibe coding.
La première, c’est le vibe coding côté tech : on s’appuie sur des agents pour générer du code, puis ce code est revu, validé et réintégré dans un pipeline de production classique, avec nos standards habituels de qualité.
La deuxième, c’est le vibe coding côté produit et UX : les équipes peuvent elles aussi créer et prototyper, parfois directement dans nos repositories, mais toujours en s’appuyant sur nos standards et notre cadre technique, même si leur approche est naturellement moins technique que celle des développeurs.
Enfin, il y a le vibe coding pour les autres équipes, via des plateformes externes comme AI Studio, v0 ou Lovable, et plus récemment via Vibely, notre propre plateforme interne dédiée au sujet.
Pourquoi ce concept est-il si important selon vous ? Qu’est-ce que cela change concrètement pour vous, en tant que développeurs ?
Philippe — Avec le vibe coding, on change la manière de travailler. On passe à une approche du développement logiciel où l’on privilégie l’intuition, le ressenti et la rapidité d’itération plutôt que des spécifications détaillées ou une architecture très formalisée dès le départ.
Pierre — L’impact est très concret en termes de productivité et de rapidité : on va plus vite, on prototype plus vite, on explore plus d’options.
Même si les agents sont autonomes, il faut que quelqu’un définisse les tâches, le contexte et la manière de travailler.
On n’est plus vraiment des builders, mais plutôt des superviseurs de systèmes.
Il a fallu cadrer les usages, sécuriser l’ensemble de la pipeline, et s’assurer que cette accélération reste compatible avec nos exigences de qualité, de fiabilité et de sécurité.
Quels étaient les problèmes initiaux et les principaux défis techniques que vous avez dû relever ?
Pierre — Le premier défi c’était l’isolation : on fait tourner du code généré par une IA, donc il faut que ce soit dans des environnements sécurisés et éphémères. On utilise des sandboxes pour ça.
Ensuite il y a eu la question de la fiabilité de l’agent. Un LLM seul qui code peut partir dans tous les sens, donc on a mis en place une architecture à deux couches : un orchestrateur qui planifie et communique avec l’utilisateur, et un agent de code qui exécute. Ça permet de garder le contrôle sur ce qui est produit.
Et puis il y a tout le parcours utilisateur : comment rendre ça accessible à des non-devs sans les noyer sous la complexité technique. Le wording, les états de chargement, les erreurs, la publication… C’est un produit qu’on continue d’affiner au fil des retours.
Comment s’est déroulé le développement de l’outil ?
Pierre — On a commencé par un MVP assez rapide, en quelques semaines, centré sur le cœur : le chat IA, l’exécution dans un sandbox et la prévisualisation en temps réel. On a itéré vite en dogfooding, l’équipe utilise Vibely pour créer ses propres outils internes, ce qui nous donne des retours concrets en continu. On priorise ce qui débloque les utilisateurs réels plutôt que de suivre une roadmap figée.
Philippe — On a démarré en s’appuyant sur quelque chose d’existant en open source, et on a construit par-dessus en ajoutant des couches de sécurité et des spécificités métier. Le system prompt a été créé au fur et à mesure, avec un accent particulier mis sur le design et le respect du style de l’entreprise par défaut, notamment pour les polices et les couleurs.
Pierre — Le projet a évolué en suivant les demandes, d’abord les nôtres, puis celles des utilisateurs.
Auparavant, un projet de cette envergure aurait pris deux ou trois mois, alors qu’ici, beaucoup de fonctionnalités sont sorties très rapidement. Pour ceux qui utilisent l’outil, cela constitue une forme de formation technique indirecte : ils commencent à comprendre ce que signifie concrètement le fait de déployer.
Autant les profils de la tech sont en train de changer, autant les autres collaborateurs doivent eux aussi monter en compétences et devenir plus tech.
Comment faire pour que tout le monde, au sein de l’entreprise, puisse réellement s’en emparer au quotidien ?
Pierre — Pour moi, la démocratisation du vibe coding ne passera pas seulement par l’outil, mais surtout par l’acculturation.
Si on veut que toute l’entreprise s’en empare, il faut sortir d’une logique réservée aux experts et montrer très concrètement ce que chacun peut en tirer dans son métier : gagner du temps, explorer plus vite, prototyper une idée, automatiser une tâche simple ou structurer une réflexion.
Le sujet n’est donc pas de mettre tout le monde face à une interface et d’espérer que cela prenne. Il faut accompagner les usages, partager des exemples utiles, former aux bons réflexes et clarifier ce que l’IA sait bien faire et ce qu’elle ne sait pas faire.
Philippe — La clé, c’est donner les briques aux équipes pour qu’elles puissent jouer elles-mêmes avec les outils. Il faut montrer que tout est possible, que les utilisateurs puissent rester en langage naturel, sans avoir à se préoccuper des problèmes techniques ou bugs sous-jacents.
Il suffit que quelqu’un réalise quelque chose de vraiment sympa et qu’il le montre pour que tout change. Une tâche qui prenait une journée entière peut désormais être bouclée en dix minutes.
Cela veut donc dire qu’on peut tous développer toutes les idées qui nous viennent sans restriction, peu importe son métier et son expertise ?
Pierre — On peut tout lancer et tout essayer, mais cela a ses limites.
Avant, il y avait un temps de brainstorming pour écarter les mauvaises idées. Aujourd’hui, on développe les mauvaises idées.
Avant, on se demandait toujours s’il y avait un ROI, si cela valait vraiment le coup de passer un mois de développement sur une fonctionnalité. Maintenant, la question est devenue « pourquoi pas ? ».
Philippe — Cela peut être initié par les devs, mais aussi par des gens du produit, du marketing, des sales qui ont des besoins d’outils internes qui ne peuvent pas rentrer dans la roadmap tech.
Ils peuvent maintenant vibe coder un prototype, itérer dessus suivant leur besoin, et pourquoi pas l’utiliser en production.
Pierre — On a des outils très puissants, mais avoir les moyens de faire quelque chose ne signifie pas toujours qu’il faut réellement le faire. Il faut savoir dire stop. Cela coûte de l’argent et de l’énergie de vérifier que tout marche et que l’ensemble reste cohérent.
Philippe — Il ne faut pas oublier qu’on a une responsabilité sur le résultat : il faut vérifier le code comme si c’était nous qui l’avions écrit. Pour s’assurer de la qualité, nous avons industrialisé le process de vérification. On s’appuie sur des checks automatisés sur les PR, une validation humaine systématique par un tiers, et des socles standardisés comme notre « Vibely-stack ».
Si on ne fait pas attention, on peut se retrouver avec des données critiques en production, visibles par tout le monde. C’est pour cela que des guardrails sont en place, protégés par l’authentification et une charte IA. On utilise aussi l’IA pour détecter les soucis et suggérer des corrections automatiques à l’utilisateur.
Pierre — On entend souvent la musique de fond que le vibe coding va créer plus de mauvais code. Mais du mauvais code et des failles de sécurité, il y en a toujours eu. L’outil permet simplement de faire plus, et plus rapidement.
Notre boulot consiste désormais à faire moins d’applications classiques pour passer plus de temps à superviser la sécurité et à penser à ce que peuvent faire les gens.
On regarde les cas d’usage et les dérives, non pas pour bloquer, mais pour expliquer à l’utilisateur et à l’agent comment ils auraient dû réagir, un peu comme un prof.
Pourquoi est-il essentiel que cette pratique soit accessible à tous les collaborateurs, et pas seulement aux développeurs ?
Pierre — Les bonnes idées ne viennent pas que des devs.
Les équipes métier, parce qu’elles vivent les sujets au quotidien, savent souvent très bien ce qu’il faudrait améliorer. Si on leur donne accès à ces outils, on peut faire émerger plus de solutions utiles, plus rapidement.
Le collaborateur qui voit l’intérêt partagera son outil, l’améliorera, et fera la publicité à la fois de son outil et de l’outil qui lui a permis de le créer.
Il suffit d’une pépite pour que tout le monde se mette à creuser.
Le témoignage de Nicolas Saraiva : d’un besoin personnel à l’outil de toute une équipe
Nicolas Saraiva, Directeur Général Délégué, raconte comment il a construit MonacOrganiser avec Vibely.
Pallier les manques d’un outil « old school »
Pour l’événement Monaco 1to1, nous avions 100 rendez-vous clients de 25 minutes à programmer sur les deux jours du salon. Avec un tel volume, j’avais besoin d’un aperçu très clair, au format agenda, de tous les rendez-vous.
La plateforme officielle pour prendre rendez-vous avec les annonceurs permet d’envoyer des demandes, de les refuser ou de les accepter. Mais la vue globale est très « old school » : aucune vue agrégée sous forme de calendrier.
Mon besoin : laisser nos commerciaux réserver leurs rendez-vous. Les autres experts et moi, présents sur le salon, voulions ensuite nous greffer dessus si c’était pertinent. L’outil devait pouvoir récupérer toutes les informations (nom du commercial, du client, détails sur les projets) et les centraliser.
Récupérer l’information pour la centraliser
MonacOrganiser, c’est surtout de la collecte d’informations pour les mettre dans un outil plus visuel, agrégé, avec des filtres. Dès que j’ai terminé cette première version basique, je me suis dit que ça pouvait devenir un outil pour toute l’équipe. J’ai alors intégré de nouvelles fonctionnalités :
- Pendant le salon, 12 personnes utilisaient l’outil. Chaque rendez-vous s’ouvrait sous forme de carte avec les informations clients et les prochaines étapes.
- L’apport de l’IA : l’outil récupérait automatiquement des informations majeures sur le client des derniers mois (la vente de plusieurs magasins du réseau, par exemple) pour enrichir nos fiches.
- La mobilité : l’outil est automatiquement responsive, donc disponible en webapp sur Android et iOS, contrairement au site officiel qui n’est pas pratique sur mobile.
- Et des fonctions pratiques : filtres, prise de notes, nombre de rendez-vous de suivi prévus, indicateurs de succès du salon.
L’outil est encore utilisé après le salon pour les notes et les comptes-rendus, versés automatiquement dans le suivi. Par rapport au tableur partagé qu’on utilisait avant, le changement est net.
Mon processus de développement avec Vibely
La grande force de Vibely : je prompte, et j’ai ma preview. Dès que j’écris mon contexte, l’outil me donne des idées en plus et me propose des suggestions. On ne se pose plus de questions sur le modèle (Claude, ChatGPT ou autre), l’outil utilise le meilleur et le plus rapide pour matérialiser la preview.
J’ai développé MonacOrganiser en 3 ou 4 heures de travail effectif, par petites sessions étalées sur 4 ou 5 jours. Le vibe coding peut réellement devenir une pratique qui s’inscrit dans tous les agendas, même les plus chargés.
Au début, le plus complexe était l’hébergement et la base de données. L’équipe tech m’a aidé sur ces points au départ. Mais l’outil évolue tellement vite qu’aujourd’hui tout est intégré et je fais tout seul. Je suis passé de 90 % d’autonomie à 100 %.
Si j’avais utilisé des LLM classiques sans Vibely, j’aurais peut-être réussi à faire l’outil, mais l’hébergement, la sécurité et l’authentification auraient été impossibles à gérer seul.
Mes conseils pour se lancer quand on n’est pas tech
- N’hésitez pas. Mettez vos idées dans le prompt. La moindre phrase simple peut démarrer un projet.
- Parlez-lui comme à un expert. C’est comme si j’avais en face de moi quelqu’un qui a 20 ans d’expérience sur chaque thème que je souhaite explorer, et qui me sort toutes les bonnes pratiques en un clin d’œil.
- Zéro risque. Vous n’allez rien casser. Attention tout de même aux données que vous partagez. Avec Vibely, on travaille dans une sandbox sécurisée, donc il suffit de démarrer et d’itérer.
- Voyez large. Un petit besoin individuel est souvent partagé par d’autres. Le vibe coding permet de transformer un simple workflow en une plateforme complète.
Pour terminer, parlez-nous de l’adoption de la plateforme par les équipes
Pierre — On a des métriques précises sur l’utilisation de la plateforme. Près d’un utilisateur sur 2 est revenu créer un 2e projet. C’est le signal le plus fort d’un outil qui apporte de la valeur.
On voit aussi que 80 % des projets créés sont des projets sérieux avec plusieurs itérations. Les gens utilisent vraiment l’outil.
Et quelles sont les prochaines évolutions prévues ?
Pierre — On travaille sur plusieurs axes. L’UX d’abord : onboarding plus guidé, meilleurs indicateurs de progression quand l’agent travaille, messages plus clairs à chaque étape. Avec un côté conversationnel, l’UX doit être encore plus soignée pour une appli agentique.
Côté collaboration, l’idée c’est de permettre le partage de projets entre collègues et le travail à plusieurs. Et à plus long terme, on veut ajouter des connecteurs avec nos outils existants pour que les apps générées puissent s’intégrer directement dans l’environnement Mobsuccess : accès aux données, API internes, authentification unifiée.
Dans les améliorations à venir, l’audit de l’application produite n’est pas encore automatisé : les utilisateurs doivent encore demander un audit avant de publier leur application lorsque l’usage est externe ou sensible en termes de données. On veut intégrer ces règles d’audit automatiquement, avec un agent qui passe sur le code, recense les problèmes et les transmet à un agent Vibely qui apporte les corrections.
Philippe — Sur Vibely, il n’y a pas de roadmap figée. On se base sur les retours, les bugs, la sécurité et le comportement des gens. On a plein de métriques qu’on exploite pour affiner la plateforme.
On vise les standards les plus avancés du marché sur l’intégration de l’agentique dans nos produits. Il ne s’agit plus juste de coder avec de l’IA, ce qu’on a fait très tôt, mais de passer à la vitesse supérieure.
Aujourd’hui, tout le code qui génère du business est revu à la main, mais tout le code sur Vibely n’est pas systématiquement revu. Aux États-Unis, la tendance est de réduire au maximum la revue humaine pour ne la garder que sur les cas les plus sensibles et complexes. Je reste dubitatif sur ce point.
Le mot de la fin : un dernier conseil pour se mettre au vibe coding ?
Philippe — Sois curieux, et essaie !
Pierre — Prends l’agent de chat que tu connais le mieux, dis-lui « j’ai envie de vibe coder, t’as des idées ? ». L’agent te connaît, il va te proposer des idées. Même si c’est basique, comme une to-do list, il faut se lancer.
L’agent va te poser des questions sur ce que tu veux, tu vas itérer avec lui. C’est comme ça qu’on apprend.