78 % des salariés qui utilisent l'IA au travail le font avec leurs propres outils. Quand ils demandent à Claude ou ChatGPT de créer un outil pour répondre à un besoin métier, le code fonctionne, parfois du premier coup : c'est la magie du vibe coding. Mais à quel prix ?
Ce livre blanc s'adresse aux DSI, aux directions de la transformation et aux dirigeants qui voient ces usages arriver et veulent les encadrer sans les freiner. Vous y trouverez :
- pourquoi laisser vos équipes vibe coder leurs outils métier est une bonne idée ;
- les risques, chiffres à l'appui, du code écrit par l'IA quand personne ne le relit : failles de sécurité, code que personne ne comprend, coûts qui dérivent ;
- quatre façons d'organiser le vibe coding, de la plus libre à la plus cadrée ;
- les règles pour qu'un code écrit par un non-développeur tienne en production ;
- le cadre technique que nous avons mis en place pour automatiser le respect de ces règles ;
- trois histoires de vibe coding en conditions réelles, avec les résultats.
Lisez le livre blanc complet
Renseignez vos coordonnées pour débloquer les 6 chapitres du livre blanc.
Le formulaire n'a pas pu se charger. Désactivez votre bloqueur de publicités, puis rechargez la page.
Ce qui se passe déjà dans votre organisation
Quelque part dans votre organisation, un fichier Excel fait tourner un processus critique, et plus personne n'ose toucher à sa colonne H.
Une personne du métier l'a construit, enrichi pendant des années, et il fait circuler des montants importants. Vous savez qu'il mériterait une application, mais le sujet attend dans votre backlog, derrière des projets jugés plus stratégiques. Il y restera jusqu'au jour où le fichier cassera, avec les risques que cela implique.
Une ligne Excel disparue, 13 millions d'euros perdus
Dans un grand groupe de distribution, une ligne disparue d'un fichier Excel a suffi à faire perdre 13 millions d'euros. Le processus tournait depuis des années sur des tableurs partagés, comme tant d'autres.
Excel a fait disparaître 15 841 tests Covid
En octobre 2020, l'agence de santé publique anglaise perd la trace de 15 841 tests positifs au Covid. Le fichier Excel qui les centralisait plafonnait à 65 536 lignes, et les résultats suivants ont été ignorés sans le moindre message d'erreur. Près de 48 000 cas contacts n'ont pas été prévenus à temps.
Il est probable que certains de vos collaborateurs aient déjà identifié le problème, et décidé de le régler avec une IA.
Remplacer un fichier Excel par une application codée avec l'IA, ou demander à un assistant de produire calculs et graphiques est désormais à la portée de n'importe quel collaborateur.
Pour y parvenir, ils confient à l'IA leurs fichiers, leurs chiffres, parfois leur code, souvent depuis des comptes personnels que l'entreprise ne contrôle pas : 78 % des salariés qui utilisent l'IA au travail le font avec leurs propres outils. Les données quittent alors l'organisation.
Samsung interdit ChatGPT après trois fuites de données
Au printemps 2023, des ingénieurs de Samsung collent du code source et des notes de réunion dans ChatGPT pour gagner du temps. En vingt jours, trois fuites de données confidentielles conduisent le groupe à interdire l'IA générative à ses salariés.
4 500 conversations ChatGPT lisibles par tous sur Google
En août 2025, plus de 4 500 conversations que leurs auteurs avaient choisi de partager se retrouvent indexées par les moteurs de recherche, avec des noms, des adresses e-mail et des informations professionnelles. OpenAI retire la fonction dans les jours qui suivent.
Même lorsque les données restent en interne, le code produit par l'IA pose son propre problème.
Il fonctionne en démonstration, il a l'air juste, et il ne l'est parfois que presque : une faille de sécurité, une règle de calcul légèrement fausse, et personne pour s'en apercevoir, puisque personne ne lit ce code.
C'est la ligne perdue du fichier Excel, cette fois enfouie dans une application.
Les assistants de code par IA changent la donne : une personne qui connaît son processus peut désormais décrire ce qu'elle veut en langage naturel et obtenir une application qui fonctionne.
Le mouvement s'étend vite : Gartner prévoit que 40 % des nouveaux logiciels d'entreprise en production seront créés avec des techniques de vibe coding d'ici 2028.
La question n'est donc plus de savoir si vos équipes métier vont coder avec l'IA. Elles le font déjà. La question est de savoir si ce code tiendra en production.
Vos collaborateurs avancent sans attendre, et leur énergie est une chance : ils connaissent leur métier mieux que personne, et l'IA leur donne enfin les moyens de construire l'outil qui leur manque. Cette chance devient un atout à deux conditions.
- Leurs données doivent rester chez vous, grâce à un outil d'IA autorisé et à des règles claires.
- Leur travail doit être relu par un développeur et reposer sur une base technique solide.
Le métier garde alors son agilité et son autonomie, et la DSI garde la maîtrise.
Ce livre blanc explique comment y parvenir.
Du tableur au vibe coding : ce que chaque étape a laissé de côté
Les métiers n'ont pas attendu l'IA pour s'équiper seuls. Depuis des décennies, lorsqu'un besoin n'entre pas dans la feuille de route de la DSI, quelqu'un du métier trouve le moyen de le traiter lui-même, avec les outils qu'il a sous la main.
Cette histoire s'est déroulée en trois temps, et vous en avez probablement vécu chacun.
Le tableur : un système d'information qui ne dit pas son nom
Tout commence presque toujours par un tableur. Une personne du métier a un besoin que personne n'a le temps de traiter : elle construit un fichier, ajoute des formules, puis des macros, puis des onglets cachés.
Au fil des années, le fichier devient un système d'information à part entière. Il nourrit des décisions, fait circuler des montants importants, et seule la personne qui l'a construit en connaît les règles.
Pour la DSI, ce système reste le plus souvent invisible : il ne figure dans aucune cartographie ni dans aucun plan de reprise, jusqu'au jour où il tombe en panne. Il est aussi fragile. Une synthèse d'audits menée par le chercheur Raymond Panko a trouvé des erreurs dans 88 % des 113 tableurs réels audités depuis 1995.
Les métiers continuent pourtant de s'en remettre à lui, faute d'alternative rapide.
No-code : l'IA a pris le relais, le besoin d'autonomie des métiers demeure
L'arrivée des premiers outils no-code a apporté une première réponse structurée à ce besoin. Les logiciels sur étagère couvraient rarement les spécificités d'un processus, les outils existants évoluaient lentement, et les équipes techniques internes restaient mobilisées sur les grands projets.
Avec Airtable, Power Apps, Bubble ou Make, il devenait possible de construire une application ou d'automatiser un flux sans écrire une ligne de code.
En 2021, Gartner prévoyait que 70 % des nouvelles applications d'entreprise s'appuieraient sur des technologies low-code ou no-code d'ici 2025, contre moins de 25 % en 2020.
Beaucoup y ont vu le moyen d'avancer sans attendre la DSI.
« On aimerait développer un outil interne en no-code, ça nous évite de passer par la DSI. »
Responsable achats d'un grand groupe
Le no-code avait aussi un atout pour la DSI des moyennes et grandes organisations, celui de se maîtriser. Une plateforme d'entreprise se validait une fois pour toutes, sur quatre points :
- l'hébergement des données ;
- la sécurité informatique ;
- la conformité au système d'information ;
- le RGPD.
Les métiers construisaient ensuite à l'intérieur de ce cadre. Pour une fois, le métier et la DSI y trouvaient chacun leur compte, et de nombreux processus internes chronophages ont été numérisés, des demandes d'achat aux circuits de validation, en passant par le suivi d'interventions ou l'accueil des nouveaux arrivants.
Le no-code a toutefois un plafond. theTribe a réalisé des projets sur Bubble et sur FlutterFlow, et en connaît les limites :
- des coûts de licence ;
- des lenteurs ;
- des fonctionnalités indisponibles ;
- des bugs en production ;
- l'absence de versioning.
La logique métier reste enfermée dans la plateforme, et le jour où l'outil ne suffit plus, il faut tout reconstruire.
« Le no-code offre une autonomie formidable, jusqu'au jour où l'outil ne suit plus. Les métiers découvrent alors qu'ils ne possèdent ni le code, ni la logique, ni la possibilité de faire marche arrière. »
Benoît Vasseur, fondateur de theTribe
Le vibe coding : l'autonomie, hors de votre contrôle
Puis l'IA générative est arrivée, et avec elle un nouveau mot. Le terme de vibe coding a été lancé par Andrej Karpathy, cofondateur d'OpenAI, en février 2025. Il décrivait une façon de programmer qui consiste à « se laisser porter » : décrire, laisser l'IA écrire, tester, redemander, sans jamais lire le code produit.
Concrètement, la personne décrit en langage naturel ce dont elle a besoin, par exemple un suivi mensuel par équipe qui met les écarts en évidence. L'outil génère une première version, qu'elle teste sur ses propres données, puis elle demande des corrections jusqu'à obtenir ce qu'elle attendait.
Une première version s'obtient en quelques minutes. En novembre 2025, le dictionnaire Collins en a fait son mot de l'année, défini comme l'usage de l'IA, pilotée en langage naturel, pour écrire du code.
Pour les métiers, la promesse est considérable : le vibe coding produit du code source, que l'entreprise possède et peut faire évoluer sans dépendre d'une plateforme.
Pour vous, il supprime en revanche le cadre rassurant du no-code. Les métiers prototypent désormais eux-mêmes leurs outils internes avec v0, Lovable, Bolt ou Claude, sans hébergement validé ni contrôle de sécurité.
Le vocabulaire a d'ailleurs évolué. Un an après avoir lancé le terme, Karpathy lui-même parle d'ingénierie agentique : le code s'écrit par des agents que l'humain orchestre, en tenant le rôle d'architecte, de relecteur et de dernier contrôle qualité.
Le mot « ingénierie » rappelle que le sujet demande une méthode. Dans ce livre blanc, nous gardons le terme vibe coding parce que c'est celui que vos équipes emploient, mais chez theTribe, nous parlons plus volontiers de développement agentique.
« Le no-code a donné le pouvoir aux métiers. Le vibe coding leur donne le code. Notre métier, c'est de leur donner le cadre. »
Benoît Vasseur, fondateur de theTribe
Les promesses et les angles morts du vibe coding
Voir sa première application tourner en quelques minutes est grisant. Le vertige vient plus tard, quand il faut la sécuriser, la maintenir, la faire évoluer.
« Avant, nos clients arrivaient avec des maquettes. Aujourd'hui, ils arrivent avec un prototype qui tourne. Notre valeur, c'est de le rendre robuste, pour qu'il ne plante pas le jour où toute une équipe s'en sert. »
Benoît Vasseur, fondateur de theTribe
Ce que vos équipes y gagnent
Les gains se voient vite, et ils ne profitent pas qu'aux métiers.
Un premier outil en quelques semaines
Un outil métier attend souvent des mois un créneau dans la feuille de route de la DSI. En vibe coding encadré, un prototype validé par ses utilisateurs sort dès la première semaine, et une première version peut être en production en quelques semaines.
Des règles de gestion enfin écrites
Rétro-concevoir un tableur éprouvé oblige à expliciter des règles qui n'existaient que dans des formules et dans la tête de leur autrice.
L'application livrée s'accompagne d'une liste de règles numérotées, relisible par le métier comme par l'audit.
Un écart supérieur à 5 % est signalé en rouge.
onglet Synthèse, colonne HconfirméeLes fournisseurs étrangers sont arrondis à l'euro supérieur.
démonstration, minute 14à trancherLe total exclut les avoirs.
onglet Données, colonne FcontradictoireExemple illustratif : chaque règle porte sa source et son statut.
Moins de relais entre le métier et l'IT
Chaque passage de relais entre celui qui sait et celui qui code perd de l'information. Quand la personne du métier décrit elle-même le comportement attendu, cette perte diminue.
Des développeurs là où ils comptent
Le développeur écrit moins et relit davantage : il pose l'architecture et tranche les choix techniques, ce qui concentre son temps là où il apporte le plus de valeur.
Des projets qui redeviennent finançables
Quand l'effort de développement baisse, des projets jugés trop coûteux hier deviennent accessibles, à commencer par les refontes repoussées depuis des années.
Ces gains demandent à être mesurés plutôt que ressentis. Dans une étude contrôlée de METR, des développeurs expérimentés, travaillant sur des projets qu'ils connaissaient bien, pensaient aller 20 % plus vite avec l'IA. Sur 246 tâches, ils ont été 19 % plus lents.
Mesurer les gains réels à chaque phase permet de savoir ce que l'IA apporte dans votre contexte, au lieu de s'en remettre à l'impression des équipes.
Les limites du vibe coding : quand personne ne tient la barre
Ces gains supposent que quelqu'un relise et gouverne ce que l'IA produit. Sans cela, six risques apparaissent, de la faille de sécurité jusqu'à la facture qui dérive.
Des failles de sécurité invisibles
Une application peut fonctionner parfaitement en démonstration tout en laissant la porte ouverte : droits d'accès absents, secrets inscrits dans le code, données exposées.
Les modèles d'IA ont beaucoup progressé pour écrire du code qui fonctionne, et très peu pour écrire du code sûr.
Veracode, éditeur spécialisé dans la sécurité des applications, le mesure. Il teste régulièrement le code produit par plus de cent modèles d'IA, et vérifie deux choses : le code fonctionne-t-il, et contient-il des failles de sécurité connues ?
Les modèles progressent sur ce qui se voit à l'écran, beaucoup plus lentement sur la sécurité. Source : Veracode, mise à jour de printemps 2026.
L'illusion de compétence
Une démonstration réussie ne dit rien de la tenue en charge, de la gestion des droits ou de la reprise après incident. La même phrase revient pourtant de plus en plus souvent en rendez-vous de cadrage :
« C'est simple, on a déjà un POC qui fonctionne, il nous faut juste dix jours de plus pour avoir un SaaS complet. »
Fondateur d'une start-up
Sur un projet récent dans la santé, le prototype vibe-codé avait validé l'essentiel. Il restait à construire tout ce qui ne se voit pas en démonstration, soit plus de cent jours de travail.
- le parcours clinique
- les prompts
- les premiers retours d'utilisateurs
- l'authentification forte
- les paiements
- la gestion multi-clients
- le back-office
- la traçabilité réglementaire
- une architecture sécurisée
Un agent qui a trop de droits
En juillet 2025, un agent de code a supprimé la base de production d'une startup en plein gel des modifications, puis a affirmé qu'aucune restauration n'était possible. L'incident s'explique par l'absence de séparation entre développement et production.
Un code que personne ne comprend
Nous reprenons régulièrement des projets vibe-codés qu'il faut jeter entièrement, faute de pouvoir les sécuriser ou les faire évoluer.
Un code généré à coups de prompts se relit rarement avant d'être livré. Il est souvent sans tests, sans documentation et sans architecture d'ensemble, et chaque modification risque d'en casser une autre.
L'analyse de GitClear sur 211 millions de lignes modifiées va dans le même sens : en 2024, les blocs de code dupliqués ont été multipliés par huit, et le copier-coller a dépassé pour la première fois le déplacement de code, signe que les équipes refactorisent moins.
Quand la personne qui a écrit les prompts change de poste, personne ne sait plus pourquoi l'application fait ce qu'elle fait.
Des applications hors du radar de la DSI
Chaque outil refusé ou trop long à obtenir finit par être contourné. Hier, c'était une base Airtable montée en marge de la DSI.
Aujourd'hui, ce sont des dizaines de petites applications générées depuis des comptes personnels, chacune maintenue par une seule personne et hébergée sur une infrastructure que personne n'a validée. Que deviendront-elles quand leur autrice changera de poste ?
« Chaque mois, je découvre un nouvel outil monté dans un service sans nous. Données hébergées hors d'Europe, licences qui explosent, RGPD approximatif : le jour où ça casse, c'est vers la DSI que tout le monde se tourne. »
DSI d'une ETI
Des coûts qui dérivent
La consommation de jetons a un coût qui, sans suivi, devient une ligne budgétaire découverte en fin de trimestre.
Certains outils de code facturent désormais à l'usage. En juin 2025, Cursor a remplacé un quota de requêtes par une enveloppe de 20 $ d'usage mensuel au tarif de l'API. Des utilisateurs ont découvert des factures inattendues, faute de savoir que seul le mode Auto restait illimité. L'éditeur a reconnu un défaut de clarté et remboursé les consommations imprévues.
Le constat dépasse le code. D'après une enquête Futurum de septembre 2026 auprès de 1 636 décideurs technologiques, 46,9 % des entreprises dépensent plus que prévu en IA, contre 5,6 % qui restent en dessous de leur budget.
Sans suivi de la consommation, cette dérive se découvre après coup.
Comment organiser le vibe coding dans votre entreprise
Les risques du chapitre précédent apparaissent quand personne ne tient la barre. Une organisation peut la tenir de quatre façons, selon le degré d'encadrement qu'elle choisit, de la plus permissive à la plus structurée.
Ces quatre approches se lisent comme une progression : chacune répond à la limite de la précédente.
Laisser faire risqué
Chacun utilise l'outil grand public de génération d'applications de son choix et publie ce qui sort. C'est la situation par défaut tant que personne n'a rien décidé.
À réserver à une maquette jetable destinée à convaincre, sans aucune donnée réelle.
Prototyper, puis faire réécrire
Pour éviter que ces prototypes partent en production tels quels, la DSI peut demander à l'IT de les réécrire proprement. Le métier construit une version qui marche, sur un tableur ou des scripts, puis la transmet aux développeurs.
Un bon point de départ pour clarifier le besoin, au prix d'un développement payé deux fois et d'une réécriture qui attend encore dans le backlog.
Vibe coder dans un cadre recommandé
Pour ne pas payer deux fois le même développement, il suffit de bâtir dès le départ sur de bonnes fondations. Le métier code lui-même, sur un socle qui impose l'architecture, contrôle automatiquement chaque modification et fait relire par un développeur avant la production.
Le partenaire technique assure l'architecture, la relecture et la remédiation. Cette approche convient à un profil déjà à l'aise avec l'IA.
C'est l'approche que nous défendons, parce qu'elle combine la vitesse du vibe coding et la solidité d'un projet d'ingénierie.
Confier le travail à un partenaire pour ceux qui ne peuvent ou ne veulent pas vibe-coder
Tout le monde ne peut pas ou ne veut pas vibe-coder, et ce sont les plus nombreux. Dans ce cas, un prestataire comme theTribe prend le relais : il extrait les règles des fichiers du métier, se fait montrer le processus, valide ces règles avec lui, puis vibe-code l'écran devant lui.
Le partenaire conçoit, développe et met en production. Cette approche convient quand aucun relais interne n'est disponible.
Le métier garde la main sur le résultat sans avoir à coder, pour environ une journée de son temps au total.
Le choix n'est pas définitif. Un projet peut démarrer avec le partenaire aux commandes, puis gagner en autonomie à mesure qu'un référent interne se forme.
Ce référent travaille alors en binôme au quotidien avec un développeur, qui l'accompagne dans sa montée en compétence, avant de coder lui-même sur le socle sous la relecture du partenaire.
L'approche C coûte plusieurs fois moins cher qu'un développement réalisé entièrement par une agence. Elle demande en contrepartie un investissement en temps côté métier : c'est la seule ressource qu'un partenaire ne peut pas fournir à votre place.
Dans un cadre, sept règles à respecter
Que le métier code lui-même (approche C) ou que le partenaire le fasse (approche D), nous préconisons les mêmes sept règles dès que vous travaillez dans un cadre.
- Le métier dans la pièce dès le premier jourUne demi-journée d'atelier avec les futurs utilisateurs produit un prototype, et aucun code n'est écrit avant qu'ils aient validé l'écran.
- Partir de l'existantChaque règle de gestion est reliée à sa source et reçoit un statut (confirmée, à trancher ou contradictoire) : les contradictions révèlent souvent ce que le tableur calcule mal depuis des années.
- Contrôler par le codeUne consigne donnée au modèle n'engage à rien : des outils vérifient chaque modification et bloquent tout ce qui enfreint les règles de l'architecture.
- L'agent qui écrit ne relit jamais son propre codeUne relecture indépendante précède celle d'un humain, qui valide avant la mise en production.
- Jamais d'écriture directe en productionDéveloppement et production restent séparés : chaque modification passe par une branche, des tests et une validation.
- Mesurer le coût réelSuivre le temps, le coût et les jetons consommés à chaque phase permet d'arbitrer sur des chiffres.
- Prévoir le relaisQuand le sujet dépasse la personne du métier, un développeur reprend le travail sans repartir de zéro, parce que tous deux ont codé dans le même cadre.
Ce que la DSI peut faire dès maintenant
Quelle que soit l'approche retenue, quatre actions relèvent de la DSI et peuvent démarrer dès maintenant :
- un catalogue d'outils validés, assorti d'un processus simple pour obtenir un accès, qui tarit les abonnements personnels ;
- une cartographie des applications existantes, qui indique où se trouvent les données et combien coûtent les licences ;
- la mise en avant des réussites internes et la formation des équipes ;
- la désignation, pour chaque outil, de la personne qui le maintiendra.
Ces actions transforment un risque diffus en programme piloté.
Vous y gagnez un rôle d'appui aux métiers, là où la DSI est souvent perçue comme le gendarme du système d'information.
La Station : comment theTribe a automatisé ce cadre
Sept règles appliquées à la main demandent de la discipline sur chaque projet. C'est pourquoi theTribe les a automatisées dans un outil interne, la Station.
La Station est le socle de développement que theTribe utilise sur ses projets, et l'outil interne qui met en œuvre les sept règles du chapitre précédent. Elle rend invisible tout ce qu'un développeur chevronné mettrait en place de lui-même, pour que la personne qui vibe-code n'ait à se soucier que de son métier.
Ce qui est prêt dès le premier jour
- Les briques que tout projet refait : comptes, droits, fichiers, e-mails, back-office
- Tests, intégration continue, déploiement et supervision déjà branchés
- Une architecture hexagonale appliquée sans dogmatisme, vérifiée par script avant chaque commit
Ce que nous construisons avec vous
- Votre modèle métier et vos règles de gestion
- Vos écrans et votre charte graphique
- Vos connexions avec les systèmes existants
- Vos standards techniques et d'hébergement
Environ deux tiers du code d'infrastructure sont livrés dès le démarrage, ce qui permet de consacrer le budget au métier.
La qualité est tenue par la machine
Chaque fonctionnalité suit le même parcours en sept étapes, de la demande à la mise en production. La machine prend en charge les vérifications répétitives, et les humains gardent les décisions. Ce parcours met en œuvre trois des sept règles : le contrôle par le code, la relecture indépendante et la séparation entre développement et production.
- Métier1. La demandeLa personne du métier décrit en langage naturel la fonctionnalité dont elle a besoin.
- Machine2. L'écriture du codeUn agent d'IA écrit le code en respectant les règles d'architecture du socle.
- Machine3. Les contrôles automatiquesDes outils vérifient la cohérence du code, le respect de l'architecture, les tests et la sécurité.
- ↺ Tant qu'un contrôle échoueL'agent reçoit le message d'erreur, corrige son code et relance les contrôles, sans intervention humaine. Le code ne passe à l'étape 4 que lorsque tous les contrôles sont au vert.
- Machine4. La relecture par une seconde IAUne autre session d'IA, qui n'a pas participé à l'écriture, relit le code avec un regard neuf pour repérer ce que la première a laissé passer.
- Métier5. La vérification fonctionnelleLa personne du métier teste l'application et confirme qu'elle fait ce qu'elle attendait.
- Développeur6. La relecture humaineUn développeur relit le code et le réorganise si nécessaire, avant toute mise en production.
- Production7. La mise en ligneLe déploiement est automatisé, et l'application est supervisée dès sa mise en service.
La personne qui vibe-code garde les mêmes compétences, elle travaille simplement dans un cadre qui refuse ce qui ne tient pas la route.
Ce qui protège du code écrit par une machine
- Audit des dépendances et scan de vulnérabilités bloquants en intégration continue
- Détection des secrets et des mauvaises configurations à chaque commit
- Revue de sécurité automatisée à chaque demande de fusion
- Un délai de 24 heures avant d'accepter une nouvelle version de dépendance, contre les attaques de la chaîne d'approvisionnement
- Des tests à plusieurs niveaux : unitaires, intégration, bout en bout
- Aucun modèle ne juge un autre modèle en production : la dernière couche de garde-fous est du code
Le code produit vous appartient
Il vit dans vos dépôts et sur votre infrastructure dès la première ligne, et vous pouvez le faire évoluer avec ou sans nous.
Trois histoires de vibe coding en conditions réelles
Trois situations montrent cette démarche à l'œuvre : un tableur remplacé par une application, un chef de projet qui construit seul sur la Station, et un prototype vibe-codé encadré jusqu'à la production.
Six semaines pour remplacer un tableur
Une direction financière suit un processus mensuel sur un classeur partagé : une dizaine d'onglets, des tables de correspondance, des contrôles faits à l'œil. La personne qui le tient ne sait pas coder ; elle est accompagnée par un développeur en binôme, qui la guide au quotidien, et par un tech lead qui relit tout ce qui part en production.
- Avant l'atelierLes règles sont extraites du fichierFormules, onglets et cas particuliers deviennent une liste de règles numérotées, chacune reliée à sa cellule d'origine.
- Jours 1 et 2 · sur placeAtelier de cadrageLe métier fait la démonstration de son processus réel, les règles sont revues dans ses mots, puis le parcours est vibe-codé jusqu'à obtenir un prototype cliquable.
- Semaine 1Validation et architectureLes utilisateurs et le décideur valident l'écran. Le tech lead pose les règles que l'agent devra respecter et tranche l'origine de chaque donnée.
- Semaines 2 à 5Développement par la personne du métierElle code sur la Station, avec son binôme joignable en visio pendant qu'elle travaille, un point quotidien et une relecture continue.
- Semaine 6Mise en productionAprès la recette par le métier et la revue de sécurité, l'application est mise en ligne et le tableur archivé.
Trois semaines, zéro ligne écrite à la main
Pendant les trois semaines d'absence de notre CTO, un chef de projet de theTribe, sans profil de développeur, construit seul une application complète sur la Station : API, back-office et application mobile. Il le reconnaît lui-même : tout a été fait en vibe coding, sans vérifier le code produit.
À son retour, le CTO audite le projet pendant deux heures et se dit « très agréablement surpris de la qualité générale ». Voici ses constats, positifs comme négatifs.
Ce que l'audit a trouvé de bon
- Les standards de qualité habituels de nos projets respectés
- Une architecture claire, facile à parcourir
- Tout fonctionne du premier coup
- La règle d'architecture vérifiée automatiquement : « un vrai garde-fou, rare à ce niveau »
Ce qu'il a aussi trouvé
- Du code de modèle laissé en place, jamais nettoyé
- Un mélange de français et d'anglais dans le nommage
- Une chaîne de déploiement pas testée de bout en bout
Du prototype vibe-codé à la production
Le fondateur d'une plateforme de services à domicile, qui traite des données de santé, redéveloppe seul la nouvelle version de son produit avec l'IA. Il ne sait pas si elle peut tenir en production.
Plutôt que de tout reprendre, nous choisissons de l'encadrer : il continue de coder, un de nos développeurs relit chaque modification et outille sa façon de travailler (fichier de contexte, garde-fous, relecture automatisée, normes de projet).
À l'issue de l'accompagnement, les 9 failles de sécurité critiques identifiées à l'audit sont corrigées, 28 tickets de remédiation sont fermés, et le client exécute seul son cycle de facturation. Le fondateur constate lui-même la hausse de qualité de ses contributions.
Et maintenant, on passe à l'action ?
Vous avez parcouru les approches et les règles. Reste à les appliquer à un cas précis : un tableur critique, un outil monté par un service, un prototype vibe-codé à fiabiliser.
La prochaine étape ? Un échange 100 % gratuit et sans engagement avec nos équipes pour vous aider à cadrer votre projet.