Ça marche dans l’aperçu, ça casse en production
Les variables d’environnement, les réglages de build, une base de données qui n’a jamais existé que sur le serveur d’aperçu.
CTO à temps partagé · Vibe coding
Vous avez construit quelque chose de concret avec Lovable, Bolt, v0, Replit, Cursor, Claude Code, Codex ou Gemini. Ça marche dans l’aperçu. Le mettre sans crainte devant des utilisateurs qui paient, c’est la partie que l’IA ne peut pas finir pour vous, et c’est celle que je fais.
Les variables d’environnement, les réglages de build, une base de données qui n’a jamais existé que sur le serveur d’aperçu.
Les utilisateurs voient les données des autres, les tables ont été modifiées à la main, et il n’y a ni migrations ni sauvegardes.
Les tests de l’IA passent, l’appli non. Chaque nouveau prompt défait le précédent.
Des clés dans le code, une base de données ouverte sur Internet, et aucune idée du coût de l’hébergement à mille utilisateurs.
Trente minutes, gratuit. Montrez-moi l’appli et ce qui coince, et je vous dis franchement si je peux aider.
Une demi-journée dans votre code, votre hébergement et vos données. Nous réglons ensemble le pire blocage, et vous recevez une liste écrite de la suite, dans l’ordre.
Si vous voulez continuer : des tests qui vérifient ce que font vos utilisateurs, du CI/CD avec préproduction, les secrets hors du code, et un coût d’hébergement connu d’avance.
Je garde ce qui marche. Le but : une appli que vous, vos outils d’IA ou votre premier ingénieur pouvez modifier sans crainte, avec une séparation claire des responsabilités, des tests, de la revue de code, et des déploiements si routiniers qu’ils en deviennent ennuyeux.
Tout vit dans votre dépôt et sur vos comptes. Vous gardez tout quand je pars.
Séance de déblocage : une demi-journée, 800 USD. L’appel découverte qui la précède est gratuit.
Les missions plus longues, comme un audit approfondi ou un sprint de mise en production, suivent les tarifs de CTO à temps partagé. Hébergement, tokens et outils passent par vos propres comptes.
Essayez d’abord ; la plupart des gens à qui je parle l’ont déjà fait. Plus de prompts comblent rarement ce qui manque, parce que le manque n’est pas du code que l’IA ne sait pas écrire. Ce sont des décisions que personne n’a prises : où tourne l’appli, comment elle est déployée, ce qui est testé, et qui peut voir quelles données. Je prends ces décisions avec vous, et vos outils d’IA redeviennent utiles.
Non. Il faut connaître vos utilisateurs et leur problème. J’explique chaque choix simplement et je le mets par écrit.
Rarement. L’essentiel de ce que vous avez construit vaut la peine d’être gardé ; je répare la structure autour.
Les failles habituelles des applis construites avec l’IA : des clés d’API envoyées au navigateur, des règles de base de données qui laissent n’importe quel utilisateur lire toutes les lignes, aucune limite de débit et aucune sauvegarde. La séance de déblocage vérifie cela en premier.
N’importe quel outil d’IA convient. La plupart des applis construites avec l’IA sont des applis web en TypeScript ou en Python, ce avec quoi je travaille tous les jours. Sur mobile : Swift sur iOS et Kotlin sur Android.
Vous recevez une estimation pour votre appli avant de choisir un hébergeur, et des plafonds de dépenses sur tout ce qui est facturé à l’usage.
Au cas par cas, pour une partie des honoraires.
Dites-moi ce que vous avez construit et ce qui bloque. Le premier appel est gratuit.
Ou envoyez-moi un message :