“Tonton, tu peux me construire un bateau ?”
Je regarde le tas de briques. Je regarde le bateau déjà à moitié cassé de la semaine dernière. Je regarde la boîte (qui promet facile, rapide, fun). Et je me dis : on est exactement en train de décrire beaucoup de projets numériques.
Sauf qu’en 2026, un nouvel invité est arrivé à la table : l’IA.
Et avec elle, une tentation très humaine : “Si on peut construire vite… construisons vite.” (Et on verra plus tard pour la solidité. Et les vis. Et la notice. Et les pièces de rechange.)
Cet article est la suite naturelle de “Et si on jouait aux Legos ?” : quand une IA peut vous “monter” des pans entiers de construction, le vrai métier n’est plus seulement d’assembler des briques. C’est de décider quoi assembler, quoi acheter, et comment faire pour que ça tienne.
Les Legos, version projet web : on n’a jamais eu autant de briques
Dans le monde d’avant (disons… hier), un projet se jouait déjà à coups de briques :
- une brique “paiement”,
- une brique “emailing”,
- une brique “authentification”,
- une brique “CRM”,
- une brique “back-office”.
Votre enjeu : choisir la bonne taille de brique.
- Trop grosse : vous vous adaptez à l’outil, pas l’inverse (bonjour la rigidité).
- Trop petite : vous empilez des micro-briques et, soudain, vous faites un Jenga au-dessus d’un volcan (bonjour l’intégration fragile).
Jusque-là, c’était déjà un art : intégrer, connecter, arbitrer. Et puis arrive le moment où quelqu’un dit :
“On pourrait le développer nous-mêmes, non ?”
Et cette phrase, en 2026, a pris un petit boost de confiance.
Vibe coding : quand l’IA vous donne l’impression d’avoir dix mains
Appelons un chat un chat : vibe coding, c’est cette façon de construire où l’IA vous aide à produire très vite (écrans, logique, scripts, intégrations, prototypes… parfois plus).
C’est grisant. Ça mord. Ça avance.
Et dans beaucoup de cas, c’est exactement ce qu’il faut… au bon moment.
Le problème, ce n’est pas le vibe coding. Le problème, c’est la confusion entre :
- “J’ai obtenu quelque chose qui marche” et
- “J’ai obtenu quelque chose qui tient dans le temps”.
(Le bateau Lego qui flotte dans la baignoire n’est pas forcément celui qui survit à la mer.)
Ce qui change vraiment : le code devient moins rare, les bonnes décisions deviennent plus rares
Quand produire du code devient plus facile, votre avantage ne vient plus de “produire du code”. Il vient de tout le reste :
1) La clarté : savoir ce qu’on construit (et pourquoi)
La plupart des équipes ne manquent pas de fonctionnalités. Elles manquent de cadrage.
- Quel problème exact résout-on ?
- Pour qui ?
- Qu’est-ce qui prouve que ça marche (un indicateur, une action utilisateur, un résultat business) ?
Le vibe coding accélère l’exécution… mais n’invente pas la stratégie.
2) La confiance : fiabilité, sécurité, conformité
Pour un décideur, “ça marche” ne veut pas dire “ça marche sur mon ordinateur”. Ça veut dire :
- ça ne tombe pas,
- ça protège les données,
- ça respecte des règles (RGPD, sécurité, traçabilité),
- et ça ne vous met pas en risque au prochain incident.
Plus l’IA accélère la création, plus la confiance devient une vraie “douve” concurrentielle.
3) L’exploitation : qui fait tourner la boutique ?
Quand vous “fabriquez” un outil, vous n’obtenez pas juste un outil. Vous obtenez un animal vivant :
- logs,
- sauvegardes,
- mises à jour,
- surveillance,
- incidents,
- et parfois… “ça marchait hier”.
Beaucoup de produits meurent non pas parce qu’ils sont mal codés, mais parce que personne ne porte le run (l’exploitation au quotidien).
4) La distribution : même le meilleur produit ne se vend pas tout seul
L’IA peut vous aider à construire une fonctionnalité. Elle ne vous donne pas automatiquement :
- un réseau,
- un canal d’acquisition,
- une marque,
- une crédibilité.
Or, pour une startup, la distribution est souvent le nerf de la guerre.
Le nouveau métier (vu côté clients) : CTO = architecte d’intention
Si vous êtes associé(e) de startup, vous cherchez rarement “du code”. Vous cherchez :
- un cap,
- une capacité à décider vite,
- un produit cohérent,
- et un système qui ne vous explose pas à la figure quand ça commence à marcher.
C’est là que le rôle de CTO (externalisé, de transition, ou fractionné) évolue : moins “écrire chaque brique à la main”, plus :
- cadrer l’intention,
- poser les garde-fous,
- choisir les bonnes briques,
- et organiser le passage du prototype qui impressionne au produit qui dure.
(Et oui : parfois, ça implique de dire “non”. Ou “pas maintenant”.)
Une grille simple (sans acronyme) pour décider : acheter, assembler, vibecoder… et sécuriser
Quand un client me dit : “On fait quoi ?”, j’aime bien repartir sur quatre questions très terre-à-terre.
1) Est-ce une brique standard ?
Paiement, emails transactionnels, analytics, signature électronique… Souvent : on achète. Parce que le coût de “refaire” n’est pas le vrai coût : le vrai coût, c’est refaire + maintenir + sécuriser.
2) Est-ce votre coeur métier (votre différence) ?
Si c’est ce qui rend votre produit unique (matching, scoring, logique métier, expérience utilisateur spécifique) : souvent : on construit.
Mais “construire” ne veut pas dire “partir sans plan”. Ça veut dire :
- définir les règles,
- écrire des tests,
- documenter les décisions importantes,
- et accepter que la simplicité est une feature.
3) Est-ce un bon candidat au vibe coding ?
Très bons candidats :
- un prototype,
- une interface interne,
- une première version d’un back-office,
- un script de migration,
- un connecteur “pour voir”.
Le vibe coding est parfait pour gagner du temps quand vous savez ce que vous cherchez.
Le point clé : on “vibecode” pour apprendre vite, pas pour éviter de décider.
4) Comment on le transforme en produit durable ?
C’est la partie qu’on oublie quand on est euphorique :
- tests automatiques sur les parcours critiques,
- règles de sécurité (auth, permissions),
- monitoring,
- sauvegardes,
- et une architecture qui permet de changer une brique sans casser tout le château.
Le passage “prototype → produit” est un vrai jalon. Il mérite un vrai budget. (Sinon, vous financez une dette. Et elle prend des intérêts.)
Mini-tableau d’arbitrage (exemples concrets)
| Besoin | Tentation naturelle | Décision saine |
|---|---|---|
| “On veut envoyer des emails” | Vibecoder un système d’emails | Acheter un service + intégrer proprement |
| “On veut un mini CRM interne” | Tout acheter (outil énorme) | Vibecoder un outil simple ou choisir une brique adaptée |
| “On veut un workflow métier unique” | Acheter un SaaS et le tordre | Construire le coeur métier, connecter le reste |
| “On veut un dashboard” | Refondre toute la donnée | Commencer petit, vibecoder un POC, industrialiser ensuite |
Conclusion
L’IA change la vitesse. Elle ne change pas les lois de la gravité.
Elle rend certains morceaux plus faciles à produire, donc elle rend vos choix plus visibles :
- vous achetez quoi (et pourquoi) ?
- vous vibecodez quoi (et jusqu’où) ?
- vous construisez quoi (parce que c’est votre différence) ?
- et surtout… qui garantit que ça tient quand un client important arrive, quand le produit grossit, quand “ça marchait hier” devient une phrase quotidienne ?
La question Levanna que je vous laisse :
Dans votre produit, qu’est-ce qui est une brique interchangeable… et qu’est-ce qui doit devenir votre pièce maîtresse ?
Parce qu’au fond, l’IA ne remplace pas le métier. Elle déplace le métier : de “faire” vers “faire les bons choix” et “assumer le run”.
Rencontrer votre CTO
Vous avez une équipe, des enjeux produit, et l’impression que l’IA accélère tout… sauf les décisions difficiles ?
On peut en parler simplement, sans jargon, et surtout avec un objectif : renforcer votre capacité technique avec de la séniorité, sans recruter dans la panique.
- Mission de CTO de transition : reprendre la direction technique, sécuriser l’existant, clarifier la trajectoire (architecture, qualité, delivery, run).
- Accompagnement mensuel d’équipe : coaching, arbitrages, cadrage, montée en qualité, mise en place de garde-fous (tests, sécurité, observabilité) — pour que votre équipe avance vite et durablement.
Et promis : on peut vibecoder. Mais on le fera comme on construit un Lego qui survit à la baignoire. Pas comme un château de cartes qui tient… tant qu’on ne souffle pas.
