La Checklist Avant de Ship avec l'IA : 3 piliers que le vibe coding ignore

1 217 jours et un constat qui fait mal

Mes premiers prompts IA datent de fin 2022. GPT-3.5. Je ne me souviens plus du prompt exact, mais je me souviens de ce que j’ai ressenti : ça pouvait me libérer un temps fou. Augmenter mes compétences de développeur. Bug fix plus vite. Construire des choses que je n’aurais pas osé attaquer seul.

Sauf que la réalité de 2022, c’était autre chose. Le code généré n’était pas terrible. Les bug fix ne marchaient pas toujours, et souvent, ils créaient de nouvelles régressions. Il fallait revenir à la main, corriger, tester, recommencer. Les fenêtres de contexte étaient minuscules, les modèles limités. On passait autant de temps à corriger l’IA qu’à coder soi-même.

J’ai quand même pris l’abonnement. J’ai commencé à intégrer l’IA chez mes clients via l’API OpenAI, GPT-3.5 Turbo. Puis GPT-4 est arrivé, et là, la donne a changé. Un vrai saut qualitatif. En parallèle, j’ai testé Claude, j’ai beaucoup travaillé avec Cursor, et progressivement j’ai tout migré vers Anthropic. Aujourd’hui, Claude Code est mon outil principal.

1 217 jours plus tard, voici le constat que j’aurais aimé entendre plus tôt : le vibe coding produit du code. Il ne produit pas des logiciels.

Un logiciel, c’est du code qui marche en production. Du code testé. Du code surveillé. Du code sécurisé. Du code que quelqu’un peut maintenir quand vous dormez.

Le vibe coding, c’est du code qui marche dans le terminal. Ce n’est pas la même chose.

Le problème que personne ne veut entendre

Le vibe coding est grisant. J’en ai parlé dans Le Paradoxe du Claude Coder : cette sensation de puissance quand Claude Code génère un composant complet en 30 secondes. Quand vous shippez en une heure ce qui prenait une journée. C’est réel. C’est addictif.

Harrison Chase a raison quand il dit qu’une personne avec des agents de code vaut cinq développeurs. J’ai réagi à cette déclaration dans mon analyse. Mais voici ce que personne ne dit : ces cinq développeurs avaient cinq cerveaux. Cinq paires d’yeux pour la code review. Cinq réflexes de “attends, on a pensé aux tests ?”. Cinq garde-fous humains.

Vous, seul avec Claude Code, vous avez la puissance de cinq. Mais les garde-fous de zéro.

Et le piège est encore plus vicieux pour les non-seniors. Quand vous n’avez jamais mis en place une pipeline CI/CD, vous ne savez pas qu’il en faut une. Quand vous n’avez jamais été réveillé à 3h du matin par un crash en production, vous ne comprenez pas pourquoi le monitoring existe. On ne skippe pas ces étapes par paresse. On les skippe parce qu’on n’a jamais appris qu’elles existaient.

Robert C. Martin l’a écrit dans Clean Code, et ça n’a jamais été aussi pertinent qu’aujourd’hui :

“It is not enough for code to work.”

Le code qui marche, c’est le strict minimum. C’est le point de départ, pas la ligne d’arrivée.

Les 3 piliers que le vibe coding ignore

J’ai identifié trois angles morts systématiques chez les builders qui codent avec l’IA. Trois piliers que le vibe coding ne couvre jamais. Pas parce que l’IA est incapable de les adresser, mais parce que personne ne les demande dans ses prompts.

Ces trois piliers, ce sont les fondations du vrai software engineering. Sans eux, vous construisez sur du sable.

Pilier 1 : Tester avant de shipper

L’IA écrit du code qui marche dans le prompt. Pas en production.

Je le vois tout le temps. Claude Code génère une fonction. Elle fonctionne avec l’input donné dans le contexte. Vous l’intégrez. Ça tourne en local. Vous shippez. Et deux jours plus tard, un utilisateur entre une valeur nulle, un string vide, un emoji dans un champ numérique, et tout explose.

Ce qu’on skippe systématiquement avec le vibe coding : les tests unitaires, les tests d’intégration, les edge cases, la gestion d’erreur. Pas parce qu’on s’en fiche. Parce que le code “marche” et qu’on veut passer à la feature suivante.

Le coût est brutal. Quand un bug arrive en prod et que vous n’avez pas écrit le code, le debug devient un cauchemar. Vous ne connaissez pas les choix d’implémentation. Vous ne comprenez pas pourquoi cette variable s’appelle comme ça. Vous êtes étranger à votre propre codebase.

Robert C. Martin dans The Clean Coder est catégorique : le TDD n’est pas une option. C’est une discipline professionnelle. L’IA rend l’écriture de tests encore plus facile qu’avant. Il n’y a plus aucune excuse.

J’ai détaillé comment mettre en place une vraie stratégie de tests avec l’IA dans Tester son code IA : TDD et tests unitaires.

Pilier 2 : Automatiser le deploy, surveiller la prod

Si vous déployez en copiant des fichiers, vous n’avez pas un produit. Vous avez un prototype.

La différence entre un side project et un produit, c’est ce qui se passe après le git push. Est-ce que les tests tournent automatiquement ? Est-ce que le build échoue si quelque chose casse ? Est-ce que vous recevez une alerte quand une erreur 500 surgit en production ?

Ce qu’on skippe : la CI/CD, le error tracking, le monitoring applicatif, les alertes. On shippe à la main. On ne sait pas si le dernier deploy a cassé quelque chose. On découvre les bugs quand un utilisateur se plaint sur Twitter.

Le coût ? Vous shippez du code cassé sans le savoir. Vos utilisateurs voient les erreurs avant vous. Votre crédibilité fond à chaque incident non détecté.

Robert C. Martin parle de “boundaries” dans Clean Architecture. La frontière entre votre code et le monde extérieur. Le deploy et le monitoring, c’est cette frontière. Si vous ne la surveillez pas, vous êtes aveugle.

J’ai écrit un guide complet pour mettre ça en place, même en solo : CI/CD et monitoring pour le builder solo.

Pilier 3 : Sécuriser et héberger comme un pro

L’IA peut scanner votre code. Elle ne peut pas penser comme un attaquant.

C’est le pilier le plus ignoré, et celui où les conséquences sont les plus graves. Un bug, c’est ennuyeux. Une faille de sécurité, c’est potentiellement fatal.

Ce qu’on skippe : les headers de sécurité, le rate limiting, la validation d’input côté serveur, le HTTPS, les variables d’environnement exposées, les dépendances avec des CVE connues, le choix d’un hébergement adapté, le load testing.

Je vois des builders qui mettent des clés API en dur dans le code. Qui n’ont pas de CSP. Qui font confiance aux données qui viennent du frontend. Qui hébergent leur app sur un plan gratuit sans backup.

Le coût : une breach, du downtime, une perte de données, une perte de confiance irréparable. Votre produit peut mourir d’un seul incident de sécurité.

Robert C. Martin dans The Clean Coder parle de professionnalisme. La sécurité en fait partie. Si vous shippez un produit qui traite des données utilisateur, vous êtes responsable. L’IA ne porte pas cette responsabilité à votre place.

Le guide détaillé est ici : Sécurité et hébergement pour les builders IA.

La checklist screenshot-able

Imprimez-la. Collez-la à côté de votre écran. Cochez avant chaque deploy.

Pilier 1 : Tests

Question à se poser	Si la réponse est non
Ai-je des tests unitaires sur la logique métier ?	Demandez à Claude Code de les écrire avant de merger
Mes edge cases sont-ils couverts ? (null, vide, caractères spéciaux)	Listez 5 edge cases et ajoutez les tests
Ai-je un test d’intégration pour les flux critiques ?	Créez au moins un test end-to-end par feature clé
Est-ce que je fais tourner les tests avant chaque deploy ?	Ajoutez un hook pre-commit ou un check CI

Pilier 2 : Deploy et monitoring

Question à se poser	Si la réponse est non
Mon deploy est-il automatisé via CI/CD ?	Configurez GitHub Actions ou équivalent
Les tests bloquent-ils le deploy si ils échouent ?	Ajoutez un check obligatoire dans votre pipeline
Ai-je du error tracking en production ? (Sentry, PostHog…)	Intégrez un outil de monitoring en 30 minutes
Suis-je alerté quand quelque chose casse ?	Configurez des alertes Slack/email sur les erreurs critiques

Pilier 3 : Sécurité et hébergement

Question à se poser	Si la réponse est non
Mes variables d’environnement sont-elles hors du code ?	Déplacez tout dans des .env non versionnés
Ai-je des headers de sécurité ? (CSP, HSTS, X-Frame-Options)	Ajoutez-les dans votre config serveur ou middleware
Mes dépendances sont-elles à jour et sans CVE critique ?	Lancez `npm audit` ou `pip audit` maintenant
Mon hébergement a-t-il des backups automatiques ?	Activez-les ou changez de plan
Ai-je fait un test de charge minimal ?	Un simple `hey` ou `k6` suffit pour commencer

Ce que Robert C. Martin dirait aux vibe coders

J’ai relu la trilogie de Robert C. Martin (Clean Code, The Clean Coder, Clean Architecture) avec les yeux d’un développeur IA en 2026. Et voici ce qui me frappe : tout s’applique. Mot pour mot.

Clean Code ne dit pas “écrivez tout vous-même”. Il dit “soyez responsable de ce que vous shippez”. Que le code vienne de vos doigts, d’un générateur, ou d’un LLM, la responsabilité est la même. C’est votre nom sur le commit.

The Clean Coder ne dit pas “travaillez plus dur”. Il dit “soyez professionnel”. Un professionnel teste. Un professionnel monitore. Un professionnel ne shippe pas du code qu’il ne comprend pas dans un environnement qu’il ne surveille pas.

Clean Architecture ne dit pas “sur-architecturez tout”. Il dit “protégez vos frontières”. Entre votre code et la base de données. Entre votre code et l’API externe. Entre votre code et l’utilisateur. Ces frontières existent que vous codiez à la main ou avec Claude Code.

L’IA n’a pas rendu ces principes obsolètes. Elle les a rendus plus urgents. Parce que la vitesse de production a explosé, mais la vitesse de réflexion humaine est restée la même.

En résumé

Pilier	Sujet	Guide détaillé
1	Tester son code IA	TDD et tests unitaires
2	Automatiser et surveiller	CI/CD et monitoring
3	Sécuriser et héberger	Sécurité et hébergement

Ces trois piliers ne sont pas des nice-to-have. Ce sont les fondations qui séparent le vibe coding du software engineering. Le code qui marche dans le terminal du code qui tourne en production.

L’IA est le meilleur outil que j’ai jamais utilisé. Mais un outil sans méthode, c’est un jouet.

Un marteau ne construit pas une maison. Un développeur avec un marteau, une équerre, et un plan, oui. Claude Code est votre marteau. Ces trois piliers sont votre équerre. La méthode, c’est votre plan.

À vous de construire.

Pour aller plus loin : L’audit complet du copilote IA builder solo et le Guide Claude Code pour les non-devs.